Project

General

Profile

Feature #568

Code review G4MICE TOF code

Added by Rogers, Chris about 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
High
Category:
TOF
Target version:
Start date:
12 July 2011
Due date:
26 July 2011
% Done:

100%

Estimated time:
Workflow:

Description

Need a code review of the TOF code used for beamline "hardware" paper


Files

valgrind.log (13.1 KB) valgrind.log Rogers, Chris, 25 July 2011 16:24
run.py (446 Bytes) run.py Rogers, Chris, 27 July 2011 10:55
cards.run (217 Bytes) cards.run Rogers, Chris, 27 July 2011 10:55
process_log.py (493 Bytes) process_log.py Rogers, Chris, 27 July 2011 10:55
tof01_full.png (18.8 KB) tof01_full.png Rogers, Chris, 27 July 2011 10:55
tof01_electrons.png (12.6 KB) tof01_electrons.png Rogers, Chris, 27 July 2011 10:59
get_tof.py (1.78 KB) get_tof.py Rogers, Chris, 27 July 2011 10:59
TofRec.cc_diff (1.95 KB) TofRec.cc_diff Diff for TofRec (added code to get reconstruction efficiencies) Rogers, Chris, 27 July 2011 10:59
TofRec.hh_diff (330 Bytes) TofRec.hh_diff Diff for TofRec (added code to get reconstruction efficiencies) Rogers, Chris, 27 July 2011 10:59
TofRec.cc_diff__18 (2.37 KB) TofRec.cc_diff__18 Diffs for comment #18 Rogers, Chris, 28 July 2011 12:08
TofRec.hh_diff__18 (377 Bytes) TofRec.hh_diff__18 Diffs for comment #18 Rogers, Chris, 28 July 2011 12:08
tof_stretched.png (20.4 KB) tof_stretched.png Rogers, Chris, 10 August 2011 14:21
02875.tar (2.09 MB) 02875.tar Rogers, Chris, 10 August 2011 14:34
02878.tar (25.2 MB) 02878.tar Rogers, Chris, 10 August 2011 14:34
02880.tar (73.6 MB) 02880.tar Rogers, Chris, 10 August 2011 14:52
tof.gif (9.85 KB) tof.gif time-of-flight tof0 -> tof1 run 2887 Karadzhov, Yordan, 10 August 2011 16:17
tof_2880.png (8.89 KB) tof_2880.png Rogers, Chris, 11 August 2011 06:45
tof_2887.png (11.1 KB) tof_2887.png Rogers, Chris, 11 August 2011 06:45
Archive.tar (100 KB) Archive.tar Karadzhov, Yordan, 11 August 2011 15:28
#1

Updated by Rogers, Chris about 10 years ago

  • Priority changed from Normal to High
#2

Updated by Rogers, Chris about 10 years ago

  • Assignee changed from Rogers, Chris to Fletcher, Rob Roy

Rob, would you mind having a pass at this? I would like to do it also. Caveat - quite a short deadline. See the code review guidelines at

http://micewww.pp.rl.ac.uk/projects/maus/wiki/Code_review

If you're too busy, let me know. I think that the style etc is not really relevant because the code is legacy, so it's more just looking for bugs.

#3

Updated by Rogers, Chris about 10 years ago

Email from Rob:

I can look at the TOF code as well. Is there some specific part I
should be looking at or just all of it, because there is quite alot there,
and does that include Marks code? I will start looking at it tonight.

Rogers:
In the first instance, I think we are interested in tof code from real data to space points - and that is G4MICE. So I think that is RealData (which I know is a mess), and MICE/Recon/TOF/

RealData, I'm not sure which code is called.

Recon/TOF, I think we need:
TofCalibrationMap.hh
TofRec.hh
TofSpacePoint.hh
TofTrigger.hh
PmtKey.hh
TofChannelMap.hh
TofSlabHit.hh
TriggerKey.hh

I don't think we need:
TofTrack.hh

I have to go through it myself to really figure it out though.

#4

Updated by Rogers, Chris about 10 years ago

Progress?

#5

Updated by Rogers, Chris about 10 years ago

Valgrind report attached running against e.g. 02204. Three things:

==764== Conditional jump or move depends on uninitialised value(s)
==764==    at 0x8108F40: TofRec::GetEfficiency() (TofRec.cc:527)
==764== Conditional jump or move depends on uninitialised value(s)
==764==    at 0x81094D5: TofRec::Print() (TofRec.cc:129)
==764== Conditional jump or move depends on uninitialised value(s)
==764==    at 0x810C17E: TofRec::Process() (TofRec.cc:151)
Looks like the DataType is not getting set. This means that
  • OnRunBeginReset() is not always called, so presumably we can get the wrong calibration map and trigger.
  • reconstruction efficiency can be reported incorrectly as 0.

Valgrind sometimes gives false positives, though it does look like there is scope for DataType not to get set. Maybe this is only for non-TOF data or something? Code where DataType gets set below:

  //! Check the data type.
  if( theEvent.tofDigits.size() != 0 )
     DataType = MCData;
  else if( theEvent.tofDigits.size() == 0 && theEvent.vmefAdcHits.size() != 0 && theEvent.vmeAdcHits.size() == 0 )
     DataType = MICEData;

Edit to add: was running Step1Ensemble

#6

Updated by Karadzhov, Yordan about 10 years ago

I do not see real problem here.
theEvent.vmeAdcHits.size() == 0 -> this is alleys true because we have vmeAdcHits only in KAK data

theEvent.tofDigits.size() != 0 -> this is true if this is simul data and false if this is real data

theEvent.vmefAdcHits.size() != 0 -> this is true if this is real data and false if this is simul data

=> DataType is not getting set only if we do not have any data.

#7

Updated by Tunnell, Christopher about 10 years ago

Sounds like that needs to be a comment....

#8

Updated by Rogers, Chris about 10 years ago

Sounds dark. For example, you set variables globally for the run based on this boolean flag. Better hope this code snippet works okay (I think it does, took 5 minutes of staring - worried about OnRunBeginReset call). The fix is to initialise the flag in the constructor, so that at least tests are reproducible. Just a comment is not good enough.

  if(DataType == MICEData)
  {
     // This is for the real data.
     if(DBReader)
     {
        if(DBReader->GetCurrentRunNum() != CurrentRunNum )
          OnRunBeginReset();

        if( CurrentRunNum<0 )
          return false;
     }

     //! Read the trigger times.
     theTrigger->Reset();
     theTrigger->SetTriggerTimes( &theEvent, &ch_map);
     //theTrigger->Print();

     makeDigits();
  }
#9

Updated by Rogers, Chris about 10 years ago

So I had a dip in the code. I only really had time to go through TofRec in detail, so I took a bit of time to make a few plots also.

Looks okay, but I didn't understand how you discriminate between different particles crossing the detector apparatus. So nowhere did I see any attempt to associate, say, a digit with a trigger, or sort by time. That's fine in the assumption that only one particle crosses the detector per Process() function call. I wasn't sure but I guess Process() is called once per spill, so we expect each Process() function call to have many particles associated with it?

Anyway, that was the main potential problem I saw so I wanted to test the assumption. First I looked at reconstruction efficiencies as a function of data rate. So looking at this code snippet, line 345,

          if( Digits[station][plane][slab][0].size() && Digits[station][plane][slab][1].size())
          {
             int nDigit0 = Digits[station][plane][slab][0][0];
             int nDigit1 = Digits[station][plane][slab][1][0];
             TofSlabHit* hit = new TofSlabHit(tofSlabModules[i], theEvent.tofDigits[nDigit0], theEvent.tofDigits[ nDigit1 ] );
             if( hit->isGood() )
        ...

if we get more than one hit in the same slab, weird stuff can happen and the reconstruction efficiency goes down. I don't think we can associate incorrect Digits in the SlabHit because hit->isGood() will throw it out (there is a timing cut I think), so I think we do just get a hit on reconstruction efficiency, rather than weird, nonsensical slab hits created.

Humm, I wonder if we can see an effect in data. So certainly for low data rate, we expect one or less particle per spill. As data rates increase, we expect more particles per spill, and the chance of this sort of collision increases. The effect is biased to effect slabs in the middle more, where data rate is higher. I used the series around run number 2870-2890 to check. I was running Step1Ensemble.

Run number digit ratio slab ratio space point ratio
2875 0.943820224719 0.738095238095 0.967741935484
2876 0.954813359528 0.80109739369 0.97602739726
2877 0.947963800905 0.836515513126 0.958630527817
2878 0.956576862124 0.845593108019 0.963166144201
2879 0.957963909461 0.827961672474 0.971067859022
2880 0.952838295506 0.833527851459 0.946283095723
2881 0.943037974684 0.788678144149 0.92777859997
2882 0.930031250458 0.767692064994 0.890021371034
2883 0.925992758769 0.766607995977 0.873130411965
2884 0.911963339969 0.733401430031 0.848773474706
2887 0.863315716578 0.635782293591 0.73940663012
So I should say that Run 2875 has shallowest dipping and lowest data rate. Run 2887 has deepest dipping and highest data rate.
  • digit ratio is the ratio of digits created to digits used in slab hits
  • slab ratio is the ratio of slabs created to slabs used in space points
  • space point ratio is the ratio of space points created to space points used in tracks
    Looks like the reconstruction efficiency goes down as a function of dip depth. Could just be an effect where there is increased noise in the MICE hall (radiation off the target), but I feel it is more likely that this is an effect from the reconstruction code, as outlined above. If this is lower reconstruction efficiency as a function of rate per slab, then it can have weird effects like skewing the distributions in the beamline.

I went on to have a look at the time distribution. So I started by looking at the time distribution of particles as a function of beam rate. I made a plot of t(TOF1-TOF0); calculated RMS and mean; and looked at the number of particles in the histogram compared with the number of particles in total (i.e. including overflow/underflow), and the number of particles in the underflow bin specifically. So the distribution doesn't look too unstable. The muon peak and electron peak seems to be pretty stable, but there is a pion peak which seems to disappear at higher rate. The other thing is that there is a lot more noise at the higher dip depth. If this was just noise coming off the target (particles with velocity << c), I would expect it to scale proportional to the total number of tracks. Also, I would expect that it is not possible to have any particles faster than the electron peak, whereas there are some 25% of particles in the underflow bin for the highest rate. So I think this is reconstruction error.

file name mean RMS weight in histogram number of tracks weight in histogram / number of tracks underflow bin
2877.root 28.6999331924 0.850863517914 209.0 214 0.976635514019 0.0140186915888
2878.root 28.830971651 0.879366088187 396.0 401 0.98753117207 0.00249376558603
2879.root 28.8037330984 0.904193316593 565.0 589 0.959252971138 0.0203735144312
2880.root 28.7485055266 0.852172662859 1124.0 1191 0.943744752309 0.0335852225021
2881.root 28.7392130228 0.851001712586 1816.0 2015 0.901240694789 0.0665012406948
2882.root 28.7289708842 0.8835777481 2890.0 3519 0.821256038647 0.0957658425689
2883.root 28.7391988845 0.924331911854 3476.0 4344 0.800184162063 0.110727440147
2884.root 28.7536024124 0.921748423742 4527.0 6173 0.733354932772 0.13964036935
2887.root 28.7409062668 0.990796955485 5544.0 10422 0.53195164076 0.247073498369

I attach the time of flight plot (25. < t < 35. ns). I also remade the plot for the electron peak only - stats below (25.5 < t < 26.5 ns).

file name mean RMS weight in histogram number of tracks weight in histogram / number of tracks underflow bin
2877.root 25.9224813567 6.66400187463e-08 1.0 214 0.00467289719626 0.0140186915888
2878.root 25.7922422293 0.098218108839 3.0 401 0.0074812967581 0.00249376558603
2879.root 25.8928110675 0.0698085842649 7.0 589 0.0118845500849 0.0203735144312
2880.root 25.8599130531 0.120907495605 12.0 1191 0.0100755667506 0.0335852225021
2881.root 25.8390504292 0.091129984794 15.0 2015 0.00744416873449 0.0665012406948
2882.root 25.8475342133 0.122957873754 38.0 3519 0.0107985223075 0.0957658425689
2883.root 25.8392968408 0.106547319718 37.0 4344 0.00851749539595 0.110957642726
2884.root 25.8706020059 0.136403186183 52.0 6173 0.00842378098169 0.13964036935
2887.root 25.8164825049 0.114388819098 77.0 10422 0.00738821723278 0.247361350988

Would be interesting to do some study of effect on reconstruction efficiency etc of changing magnet currents, changing from +ves to -ves. For now I think that is enough. Also I should add that I'm a novice, so probably doing something hideously wrong! But that's what I found.

I also attach the scripts I used to make these plots, and the hacks in TofRec I made to interrogate on reconstruction efficiencies.

#11

Updated by Karadzhov, Yordan about 10 years ago

Your assumption that TofRec::Process() is called once per spill is wrong.
It is called once per particle event (particle trigger).
Nevertheless the particle event can contains more than one particle.
This case is treated in the beginning of makeSpacePoints() by using
one method of the class TofTrigger.

#12

Updated by Rogers, Chris about 10 years ago

Okay, I thought that was likely - otherwise the code makes no sense. So why is the reconstruction efficiency dropping so much when the dip depth is increased? I don't believe this is just some background radiation level... must be multiple particles in each trigger, right?

#13

Updated by Karadzhov, Yordan about 10 years ago

I do not think that the efficiency of the reconstruction is dropping a lot. When we run having hight event rate we also have higher noise rate. This is making your ratios, to go down.

#14

Updated by Rogers, Chris about 10 years ago

25% of particles are reconstructed with speed greater than speed of light. Surely that has to be a bug? Even if there is background radiation off ISIS, it should be at worst proportional to event rate.

#15

Updated by Rogers, Chris about 10 years ago

Interesting - I added a check to look at average number of tracks generated per Process() function call, as track ratio. In fact, the number of tracks created per Process() increases strongly with deeper dip depth. (Maximum track ratio is 3 as we are allowed one track for each of TOF0->TOF1, TOF0->TOF2, TOF1->TOF2)

Run number digit ratio slab ratio space point ratio track ratio
2875 0.943820224719 0.738095238095 0.967741935484 0.0434782608696
2876 0.954813359528 0.80109739369 0.97602739726 0.333774834437
2877 0.947963800905 0.836515513126 0.958630527817 0.635782747604
2878 0.956576862124 0.845593108019 0.963166144201 1.0777666999
2879 0.957963909461 0.827961672474 0.971067859022 1.048669695
2880 0.952838295506 0.833527851459 0.946283095723 1.41335044929
2881 0.943037974684 0.788678144149 0.92777859997 1.54775124931
2882 0.930031250458 0.767692064994 0.890021371034 1.70759717314
2883 0.925992758769 0.766607995977 0.873130411965 1.77933921363
2884 0.911963339969 0.733401430031 0.848773474706 1.83129663675
2887 0.863315716578 0.635782293591 0.73940663012 1.91271372497

Why is the ratio so low initially? Is it really 5 % of triggers only that have a real particle associated with them? Why does it go up so dramatically? Are most of these tracks just getting generated from noise? Doesn't make much sense to me, probably means I'm doing something wrong!

#16

Updated by Rogers, Chris about 10 years ago

ps: added actual numbers

[?1034hmultiprocessing library not detected - subprocess library will not be available
2875 TofDigs: 168/178 TofSlabs: 62/84 TofSpacePoints: 30/31 Track: 27 NProcessCalls: 621
2876 TofDigs: 1458/1527 TofSlabs: 584/729 TofSpacePoints: 285/292 Track: 252 NProcessCalls: 755
2877 TofDigs: 3352/3536 TofSlabs: 1402/1676 TofSpacePoints: 672/701 Track: 597 NProcessCalls: 939
2878 TofDigs: 6036/6310 TofSlabs: 2552/3018 TofSpacePoints: 1229/1276 Track: 1081 NProcessCalls: 1003
2879 TofDigs: 9184/9587 TofSlabs: 3802/4592 TofSpacePoints: 1846/1901 Track: 1616 NProcessCalls: 1541
2880 TofDigs: 18850/19783 TofSlabs: 7856/9425 TofSpacePoints: 3717/3928 Track: 3303 NProcessCalls: 2337
2881 TofDigs: 34270/36340 TofSlabs: 13514/17135 TofSpacePoints: 6269/6757 Track: 5575 NProcessCalls: 3602
2882 TofDigs: 63390/68159 TofSlabs: 24332/31695 TofSpacePoints: 10828/12166 Track: 9665 NProcessCalls: 5660
2883 TofDigs: 79540/85897 TofSlabs: 30488/39770 TofSpacePoints: 13310/15244 Track: 11902 NProcessCalls: 6689
2884 TofDigs: 121396/133115 TofSlabs: 44516/60698 TofSpacePoints: 18892/22258 Track: 16934 NProcessCalls: 9247
2887 TofDigs: 267406/309743 TofSlabs: 85006/133703 TofSpacePoints: 31427/42503 Track: 28750 NProcessCalls: 15031
#17

Updated by Karadzhov, Yordan about 10 years ago

1. As it was discussed several times the tof reconstruction ends with space points. Creation of the tracks is officially not part of the tof reconstruction and it was added by Mark just to make his analysis simpler. As it is now the track creation code is completely useless in the case of multiple hits. However, to have less than 1 track when the trigger is TOF1 is something strange. You can try to investigate this.

2 Please explain with more details the v>c problem.

#18

Updated by Rogers, Chris about 10 years ago

1. I should say that the code in Recon/TOF - you are responsible for it. I don't know who wrote what, but at the end of the day if it's got bugs then it's your job to get it fixed. I realise you're busy, but we've got more people on TOF code now. If Alain wants this paper out, then I think we've got to look at this stuff.

It is strange - I'm not quite sure I believe it, but that's what the code is telling me. Perhaps you can see a problem in the code I made (which was only something quick to understand what's going on). I had a look at the space point reconstruction also, table below, but the behaviour also has problems:

multiprocessing library not detected - subprocess library will not be available
2875 TofDigs: 168/178 TofSlabs: 62/84 TofSpacePoints: 30/31 SpacePoints-Tof0-Tof1-Tof2: 11 12 8 Track: 27 NProcessCalls: 621
2876 TofDigs: 1458/1527 TofSlabs: 584/729 TofSpacePoints: 285/292 SpacePoints-Tof0-Tof1-Tof2: 88 113 91 Track: 252 NProcessCalls: 755
2877 TofDigs: 3352/3536 TofSlabs: 1402/1676 TofSpacePoints: 672/701 SpacePoints-Tof0-Tof1-Tof2: 220 264 217 Track: 597 NProcessCalls: 939
2878 TofDigs: 6036/6310 TofSlabs: 2552/3018 TofSpacePoints: 1229/1276 SpacePoints-Tof0-Tof1-Tof2: 414 490 372 Track: 1081 NProcessCalls: 1003
2879 TofDigs: 9184/9587 TofSlabs: 3802/4592 TofSpacePoints: 1846/1901 SpacePoints-Tof0-Tof1-Tof2: 604 722 575 Track: 1616 NProcessCalls: 1541
2880 TofDigs: 18850/19783 TofSlabs: 7856/9425 TofSpacePoints: 3717/3928 SpacePoints-Tof0-Tof1-Tof2: 1293 1464 1171 Track: 3303 NProcessCalls: 2337
2881 TofDigs: 34270/36340 TofSlabs: 13514/17135 TofSpacePoints: 6269/6757 SpacePoints-Tof0-Tof1-Tof2: 2275 2479 2003 Track: 5575 NProcessCalls: 3602
2882 TofDigs: 63390/68159 TofSlabs: 24332/31695 TofSpacePoints: 10828/12166 SpacePoints-Tof0-Tof1-Tof2: 4296 4357 3513 Track: 9665 NProcessCalls: 5660
2883 TofDigs: 79540/85897 TofSlabs: 30488/39770 TofSpacePoints: 13310/15244 SpacePoints-Tof0-Tof1-Tof2: 5537 5352 4355 Track: 11902 NProcessCalls: 6689
2884 TofDigs: 121396/133115 TofSlabs: 44516/60698 TofSpacePoints: 18892/22258 SpacePoints-Tof0-Tof1-Tof2: 8266 7703 6289 Track: 16934 NProcessCalls: 9247
2887 TofDigs: 267406/309743 TofSlabs: 85006/133703 TofSpacePoints: 31427/42503 SpacePoints-Tof0-Tof1-Tof2: 17326 13633 11544 Track: 28750 NProcessCalls: 15031

It's weird - maybe there are triggers just for spill start or spill end? Or some other reason Process gets called (I only count the number of process calls)? Again, I attached a new diff for TofRec.hh. TofRec.cc

2. I plot "t" branch from Step1Ensemble output root tree. The "underflow bin" column above is the proportion of particles with time to the left of the histogram, i.e. before the electron peak. Assuming electrons have v = c, these are travelling faster than c, right?

#19

Updated by Rogers, Chris about 10 years ago

So I think that the issue with noise blocks both beamline papers:
  • Reconstruction efficiency report is incorrect - efficiency is rate-dependent
  • Position of the electron peak can be pulled depending on how the mean is calculated (my guess is we just calculate the mean, don't do a fit to the peak, so "pedestal" can pull in either direction)
  • Effect on transverse distribution? We get noise distribution in addition to truth distribution - may effect things, depending on whether there is an upper timing cut

Can we discuss on the phone?

#20

Updated by Rogers, Chris about 10 years ago

  • Assignee changed from Fletcher, Rob Roy to Karadzhov, Yordan

Yordan, I want to give you a chance to respond to this tracker, but I feel the time pressure to get this beam line paper published. Now NuFact is done, when do you think you will have a response? If we can't resolve this as stupid Rogers error in the next few days, I think it needs exposure to management.

#21

Updated by Karadzhov, Yordan about 10 years ago

I am working on this right now.

#22

Updated by Tunnell, Christopher about 10 years ago

How do we regenerate the efficiency plot within the beamline paper? Is that still true?

#23

Updated by Rogers, Chris about 10 years ago

Great many thanks. Any estimate for when you will be able to confirm the results?

#24

Updated by Rogers, Chris about 10 years ago

Email from Yordan:

I am not able to run your code. The first problem is that, I don't have
all of the data files and it seems that it is not possible to get data
from GRID now. I tried to modify your code and to run using some data
file I have. I am attaching my modification of your run.py file. Take
into account my very poor knowledge of python. When typing 'python
process_log.py (after running mytest.py) I have

File " process_log.py", line 7
digit_ratio = float(words2.split('/'([0]) / float(words2.split('/'([1])
ValueError: could not convert string to float: --

Also even after installing MatPlotLib by using yum I have "MatPlotLib
not detected".
I wonder why you are doing such a complicated gymnastic. We have enough
tools for histograming in g4mice?

It is not very nice to send me code without even one word for
explanation what you are doing after being so severe about putting
comments in the code.

We need to have this problem solved at the latest tomorrow because I am
off next week.

Response:

Sorry, I guess I just stick things in scripts without thinking. It wasn't production code, really just 5 lines of personal code that I thought you might like to see. So what the script is doing:

  • Make a cards file like cards.2875:
numEvts 100000000
MiceModel MICEStage2/Stage2.dat
PlotFrequency 1000
!
TofTriggerStation 1
!
DataLocation /home/cr67/backup/tof_analysis_data/dip_depth_series/02875/
runNumber 2875
  • Run
    ./Step1Ensemble cards.2875
    
  • Look at the last line in the output to read off line like
    2875 TofDigs: 168/178 TofSlabs: 62/84 TofSpacePoints: 30/31 SpacePoints-Tof0-Tof1-Tof2: 11 12 8 Track: 27 NProcessCalls: 621
    

For the TOF stuff, look at (note log y):

This noise distribution stretches forwards and backwards off the edge of the histogram. I wanted to make the actual electron/muon peak visible.

#25

Updated by Rogers, Chris about 10 years ago

#26

Updated by Rogers, Chris about 10 years ago

#27

Updated by Rogers, Chris about 10 years ago

Okay, redmine won't let me upload any more data files. It's probably exploding... but there's a couple to get starte

#28

Updated by Karadzhov, Yordan about 10 years ago

I attach a time-of-flight plot for run 2887. This run looks worst in your plot.
I see some V>C noise but the noise/signal ratio is definitely not 1/10 as in your plot.
If you want to reproduce my plot, just run

./TofControlTool cards.in

using data card like

MiceModel MICEStage2/Stage2.dat
TofTriggerStation 1
DataLocation yourpath
DaqVerboseLevel 1
DoPMTCheck 0
DoTofPlots 1
runNumber 02887

all plots produced by the application will be in ControlHistos.root

#29

Updated by Rogers, Chris about 10 years ago

What's the difference between Step1Ensemble and TofControlTool? Which one (if either) was used to generate plots in the beamline papers?

#30

Updated by Karadzhov, Yordan about 10 years ago

I know almost nothing about Step1Ensemble.
TofControlTool is very simple application. It just fills histograms.

#31

Updated by Rogers, Chris about 10 years ago

Email from Mark (may get put into the issue automagically by Redmine also, that feature doesn't always work):

Chris,

Step1Ensemble is used for the paper. BUT it may require a specific
version of the data unwrapping and TofRec, things I don't have control
over, and which may have changed. (Tim's difficulties etc...) S1E
itself does very little: it unwraps the raw data files and applies
Yordan's TofRec code in the standard way, and puts the results into
TTrees for analysis by Step1Reconstruction. I did this once (for
consistency and because it takes a very long time) shortly after the
Step 1 data taking finished. I used the most recent G4MICE release
available at that time.

The point of the TTrees is the same as the point of designing TTrees
now to replace text files in persistence. My code pre-dated these,
hence their existence.

Mark

#32

Updated by Rogers, Chris about 10 years ago

I ran TofControlTool with my diagnostic output switched on, for run 2877 (runs quicker than 2887 as data file is smaller). I get:

TofDigs: 3352/3536 TofSlabs: 1402/1676 TofSpacePoints: 672/701 SpacePoints-Tof0-Tof1-Tof2: 220 264 217 Track: 597 NProcessCalls: 938

which is the same as before. The main difference I can see is that TofControlTool seems to call

tofRec.GetSpacePoints()

but Step1Ensemble does not. This seems to contain some vector of "good" space points, although how that selection is made I'm not quite sure. Will investigate tomorrow.

#33

Updated by Karadzhov, Yordan about 10 years ago

As you can see from this email, I am not the right person to address this problem. I can try to investigate the efficiency problem. But according to your report, if there is a problem, this problem is in TofRec::MakeTrack. As I already explained this is not official part of the reconstruction. It is more like a part of the Mark's analysis. I tried to put order there but my code was bypassed. You can find my version of the MakeTrack code in the if(false) { .....} at the end of the function.

It may be useful to try to make your V>C plot more informative because as it is now it is very hard to understand what you see. Use just one run (2887 for example) and reduce the bin size. Also remove the logarithmic scale.

#34

Updated by Rogers, Chris about 10 years ago

Well, maybe there is a problem in the track finding algorithm. But

  • I still don't understand the pattern of reconstruction efficiencies outlined in, say #note-9.
  • I don't understand how we can get more space points than triggers in TOF0 for e.g. 2887 in #note-18.
  • I don't understand how we can get ratio space point:trigger of 50% for typical dip depths. Really half the triggers are bad?
  • I don't understand how we can get 10-20% more triggers in TOF1 than TOF0 for e.g. 2880. Are these neutrals?

I think this needs proper investigation.

#35

Updated by Rogers, Chris about 10 years ago

Please find attached separate TOF plots for 2880 and 2887:

I realise I cut the top off the plot previously which made things look worse than they are. Sorry about that.

#36

Updated by Karadzhov, Yordan about 10 years ago

I still don't understand the pattern of reconstruction efficiencies outlined in, say #note-9.
I don't understand what you don't understand.

I don't understand how we can get more space points than triggers in TOF0 for e.g. 2887 in #note-18.
Only small fraction of the particles passing trough TOF0 are hitting TOF1 (triggering the DAQ)
For one particle event (particle trigger) we may have more than one particle hitting TOF0.
Actually this happens quite frequent when we run at hight rate.

I don't understand how we can get ratio space point:trigger of 50% for typical dip depths. Really half the triggers are bad?
This is not true. I do not know what you mean.

I don't understand how we can get 10-20% more triggers in TOF1 than TOF0 for e.g. 2880. Are these neutrals?
First contribution : particles crossing the uncalibrated part of TOF0.
Second contributions : neutrals.
Third contribution : cosmic triggers.
Fourth contribution : triggers generated by noise.

#37

Updated by Rogers, Chris about 10 years ago

Take, for example, typical dip depth run 2879:

2879 TofDigs: 9184/9587 TofSlabs: 3802/4592 TofSpacePoints: 1846/1901 SpacePoints-Tof0-Tof1-Tof2: 604 722 575 Track: 1616 NProcessCalls: 1541

Number of calls to process() is 1541 but only 722 space points at Tof1. So 50% of triggers are noise?

#38

Updated by Karadzhov, Yordan about 10 years ago

OK this is definitely a bug :)
I did some investigation and I will show you what I found.
First copy the modified version of TofRec and DATEDAQReader and TofControlTool and recompile. All modifications I did are just to print some useful information to the screen. You can check this using diff.
After this do:
./TofControlTool card.in>log

using

MiceModel MICEStage2/Stage2.dat
TofTriggerStation 1
DataLocation /home/yordan/g4mice/data/
DaqVerboseLevel 1 !!! THIS IS IMPORTANT
DoPMTCheck 0
DoTofPlots 0
runNumber 02880

the log file is also attached.

you can see in the log file that the START OF RUN, START OF BURST and END OF BURST are always surrounded by some empty events.
I do not have any idea what is producing this junk. It may be the unpacking or the DateReader, but is probably not the DAQ because we do not see such a thing in MAUS (I have to check this). So when the number of the real events per burst is small the ration of the junk is big.

This was never found before because in my studies of the efficiency of the reconstruction, I count as real only the events when we have at least 2 slab hits in the trigger station (this is the minimum requirement for any measurement of the time).

#39

Updated by Rogers, Chris about 10 years ago

Great that we found a bug. From what you describe, it probably doesn't affect physics results (looks like extra empty triggers I guess) but I think we would want to check we understand what's going on - that there's not some other problem hidden in this.

#40

Updated by Rogers, Chris about 10 years ago

Just to let you know, I've been assigned to report on this at the MICE VC beginning October - would be great to say that the issue was closed. Any update?

#41

Updated by Rogers, Chris almost 10 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100
#42

Updated by Rogers, Chris almost 10 years ago

  • Target version changed from Future MAUS release to MAUS-v0.0.8

Also available in: Atom PDF