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.

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)

• 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

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.

• 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.

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).

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.

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?

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.

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(words².split('/'([0]) / float(words².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.

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

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

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.

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).