Task #25479

Understand channel-to-channel response variation in data-driven dE/dx

Added by David Adams 2 months ago. Updated about 1 month ago.

Start date:
Due date:
% Done:


Estimated time:


Aleena gave a nice talk on her Michel analysis at the collaboration meeting. I understood from comments that the channel-to-channel response variations she reported a couple months ago are still not understood. If so, I would like to help understand and resolve the problem.

Aleena, can you confirm the issue is not understood and point me to the talk where you showed the problem?

Thanks you. --david

1ev_charge_channel.pdf (20.7 KB) 1ev_charge_channel.pdf Francesca Stocker, 03/01/2021 08:36 AM
sigstren-trig8-run005776evts000000-006000.png (76.2 KB) sigstren-trig8-run005776evts000000-006000.png David Adams, 03/01/2021 11:27 AM


#2 Updated by David Adams 2 months ago

  • Subject changed from Understand channel-to-channel response variation in Michel analysis to Understand channel-to-channel response variation in data-driven dE/dx

Indeed it is this talk by Francesca that I have in mind. I apologize to both Aleena and Francesca.

I will take Aleena off the ticket.

Am I correct that we still do not understand the origin of the effect?

#3 Updated by Tingjun Yang 2 months ago

I don't think we understand this. There are a few guesses: variations in wire tension, shaping time, etc.

#4 Updated by David Adams 2 months ago

From Francesca:

Hi David,

this is the last of the conversation about these gain variations.  I haven’t had time to go down the rabbit hole with this topic but if you have time to look at this it would be interesting for sure!
I was having trouble retrieving the uncalibrated values from the files since the module I am using is not working on those files.

We were tossing the idea that maybe the transparency of the APA3 could play a role in it (as explained in the slides)

Also, from looking at dEdx vs wire I was doing this study / method development:

if you have any comments or suggestions from your side concerning this study I’d highly appreciate that too :)


It should be easy write a container of recob:Wire with the collection-plane calibrated ROIs without the wirecell deconvolution. Would you be able to remake your plots with those charge measurements?

#5 Updated by Francesca Stocker 2 months ago

yes if I can get the data for the beam particles in a root file it should be fine to produce the plots.

#6 Updated by David Adams 2 months ago

I am not sure what "data for beam particles" means. Maybe Tingjun can help.

#7 Updated by Francesca Stocker 2 months ago

so let me try to specify for this analysis I was looking specifically at beam Pions from run 5378, this means that is a precisely localised sample in the detector. the effect is well visible with that sample as these tracks are all affected by lifetime & track angle in the same way. if I take CRT tagged muons the effect is visible too but fainter, I believe this is due to the fact that lifetime & orientation affects the tracks differently depending on their location in the drift coordinate so it is smeared out.

I would suggest to look at the same run 5378 before deconvolution and select the particles that make it through the beam window in order to have the same sample as what I presented. Then one can look at the charge on a wire-to-wire basis for the beam particles and see if we can still see the same effect.
does that make sense to you?

#8 Updated by David Adams 2 months ago

I can (and would like to) create a configuration (i.e. fcl) of the dataprep module that will write out ROIs (i.e. recob::Wire objects). Can you use those directly with the pions from the current production or do we need to rerun full reco within that same job?

#9 Updated by Francesca Stocker 2 months ago

I am not 100% aware of what needs to be done. if it is of any help I was using following variables in the PDSPanalyzer_module:

reco_beam_dEdX_NoSCE vs reco_beam_calo_wire which should be from trackUtils Calorimetry Objects, that comes from a recob::Track object, which does need reconstruction I reckon. so I guess yes, we need it?

I guess if we can get out the deposited charge vs wire and we manage to filter for just beam particles it should be easy to reproduce comparable plots to what I was showing.

#10 Updated by David Adams 2 months ago


I see two approaches:

A. We produce data files with the ROIs and then match them to your existing tracks using the channel-tick information. The ROIs can be in recob::Wire format with the matching in an art module or we can write them out int a Root TTree do the work in Root. We will be looking at charge rather than energy deposit.

B. We run full reco replacing the wirecell ROIs with the ones above. I do not yet have 2D deconvolution and so the recob::Wire collection would have to be hybrid with the above collection channels and induction channels from wirecell. I am working on the 2D deconvolution but that is probably another month away.

I have been assuming A but it sounds more like you expect B. Tingjun, how do you think we should proceed?

#11 Updated by Francesca Stocker 2 months ago

David, how much time does it take you to produce a little test file with A? if it's not an immense amount of work we should try to see if we're able to do it that way. I think it doesn't matter if we look at charge or energy. In fact, the more "raw" we are in the information the better we can understand if we're dealing with a detector effect, something coming from deconvolution or other changes that are done on the collected signals.

#12 Updated by David Adams 2 months ago

I agree completely. I will provide a few or one event and you can have a look. Do you want run 5387? Can you give me a few event numbers? I will get something in a day or two. Thanks. --david

#13 Updated by Francesca Stocker 2 months ago

it's run 5387 (1GeV)
here are a few event numbers of beam particles that are tagged as beam particles by the beam instrumentation and pass the beam window cuts:
  • Row * event * ****************
  • 0 * 115476 *
  • 2 * 115903 *
  • 4 * 116192 *
  • 5 * 116373 *
  • 7 * 116379 *
  • 8 * 116443 *
  • 9 * 116638 *
  • 11 * 116649 *
  • 12 * 116651 *
  • 13 * 116856 *
  • 14 * 116862 *
  • 15 * 50554 *
  • 16 * 50618 *
  • 20 * 50979 *
  • 25 * 51267 *
  • 27 * 51324 *
  • 31 * 51578 *
  • 32 * 51594 *
  • 33 * 51735 *
  • 35 * 51995 *
  • 36 * 19460 *
  • 37 * 19959 *
  • 38 * 19963 *
  • 39 * 20161 *
  • 40 * 20421 *

#14 Updated by David Adams 2 months ago

I think I have job producing ROIs.

Can someone tell me how to write out only the ROIs and not the raw data, etc.

#15 Updated by David Adams 2 months ago


I have put ROIs for one event here:


and the full event here


Only the collection plane for APA 3 is included.

Please let me know if either works for you and I can process more events.


#16 Updated by David Adams 2 months ago

Francesca, are you able to view the ROIs in either of these files? --david

#17 Updated by Francesca Stocker 2 months ago

David Adams wrote:

Francesca, are you able to view the ROIs in either of these files? --david

hi david, I'm sorry I was gone in the weekend. I can't access the nashome directories of others than myself.
could you move it to /dune/data/users/dladams/something?

sorry this week is a bit full for me but I'll try to just see if I can look at it the way I did with the other files.
then I can do it probably next week

#18 Updated by David Adams 2 months ago

No problem waiting. I just want to make sure you aren't waiting on me for anything. I should have given you the real directory for these files:


Let me know if you cannot read this and I will check the permissions.

#19 Updated by Francesca Stocker 2 months ago

Hi David,
I looked at the rootfiles you put there for me. I am very unfamiliar with the structure so I didn't get really far. unfortunately I don't have plenty of spare time to hammer a way out on how to associate the beam particle charge deposition and separate from other particles within the event.

is it feasible for you to somehow store vectors that contain for one event
deposited charge, at corresponding wire, at corresponding tick? maybe we can then already sort with the tick information the beam particles.. and still avoid reconstruction

I'm quite used to the format of the PDSP Analyzer module, so that style what I am able to work quickest with. ( [[]], [[]])

I was working with the branches


#20 Updated by David Adams 2 months ago


The event data file I created is intended (by art) to be viewed in an art event-processing job, i.e. retrieving the data from inside an art module. It sounds like you are instead working inside Root. In theory one could directly find the recob::Wire branches in the event file and extract the information you request but I am not sure how easy that is in practice. I add Mike and Tom in CC. Perhaps one of them or Tingjun can comment on the feasibility of that approach.

I could instead write out a TTree with one entry per ROI, with the following information:

Channel number
# ticks
starting tick
charge intergral

or one entry/event/channel adding the number of ROIS and making the last three arrays of that length.

Let me know if either or both of these approaches would work for you. Right now, I am leaning toward the second.

#21 Updated by Francesca Stocker about 2 months ago

Hi David,

so I need to compare the charge integral for the same particle trajectory (the one of the beam particle, that's why the reco objects from pandora facilitate the work here) on a channel-by-channel basis.
what is the difference between your proposed branches #ticks and starting tick?
is it possible with

Channel number
# ticks
starting tick
charge intergral

to isolate beam particles? I assume by requesting a certain tick-range? do you know which one already?

#22 Updated by David Adams about 2 months ago

If an ROI extends from tick 1000 to 1010, the starting tick is 1000 and the # ticks is 11.

I was going to write all the APA3 ROIs for your event list. But if you prefer I can also add a cut on the ticks.

#23 Updated by Francesca Stocker about 2 months ago

I think an appropriate cut on the tick range to only include beam particles would be desirable.

#24 Updated by David Adams about 2 months ago


I have put TTree with ROIS for one event at


The branch names should be pretty obvious: isam is the first tick in the ROI, nsam is the # ticks, and qke is the charge in ke.

For example, to display the beam region for this one event and plane:

adcrois->Draw("channel:isam+0.5*nsam", "qke*(isam>4000&&isam<5000)")

Please let me know if this will work for you and then we can discuss the format for multiple events, e.g. one file or tree per event.

#25 Updated by Francesca Stocker about 2 months ago

Hi David,

so the plot attached should be the charge vs channel (i.e. wire) for the beam particle region right?
Now we just need to include all particles of several events in this plot and we will (or won't) see the strange shifted pattern emerge as we accumulate stats?
if the Tree has a qke, channel as vecotrs per event then it's easiest directly to plot this from terminal. because then one tree would be able to hold all events.
so each qke and channel entry in the tree corresponds to an event being two vectors with all the qke vs corresponding channel at the same position within the vector.
cheers Francesca

#26 Updated by David Adams about 2 months ago

I had in mind that you would match the ROIs to your tracks, e.g. keep the closest for each channel, but we certainly also just use a timing cut as in my example. In either case, if you send me an event list, I can produce a tree with those events.

I did point you earlier to plots averaging over all ticks for thousands of events (call signal strength). Here I include one of those switching to a linear scale. I believe the channel-to-channel fluctuation here are smaller than what you see. Is that correct?

#27 Updated by Francesca Stocker about 1 month ago

Hi David,
coming back to this.
I think it is easiest and quickest to just use the timing cut. it's important to look at charge that came in at roughly the same timing (same location within the drift) to see the fluctuations. I don't think it matters to try to match it to tracks.
the run I looked at was 5387, so any N-events from that specific run should be a good start.

I think the fluctuations I saw are bigger than what you see on the signal strength. also I saw a bit of a pattern for going from channel to channel. are yours just collection channels? because mine are just collection channels as I look at the wires where charge was deposited

#28 Updated by David Adams about 1 month ago


The signal strength plots only include collection channels.

As a next step, I have made a tree with 100 events from run 387. The file is here:


Please have another look and let me know if this is what you want. I have not imposed a cut on tick, but you and easily do that with variable "isam", e.g. "isam>=4000&&isam<5000". Note the charge is now in variable qroi (instead of qke) and I have added the pulse height limits in "hmin" and "hmax" and the channels status in "status" (1=bad, 2=noisy, 0 otherwise). The former can be be used to impose a new threshold.

I will start producing trees with 1000 events each. Let me know how many of those you want.


Also available in: Atom PDF