Project

General

Profile

Bug #1629

Changes in MAUS processing

Added by Nugent, John over 7 years ago. Updated about 7 years ago.

Status:
Open
Priority:
Urgent
Assignee:
-
Category:
Global Reconstruction
Target version:
-
Start date:
23 February 2015
Due date:
% Done:

0%

Estimated time:
Workflow:
New Issue

Description

Reconstructing with different versions of MAUS gives different results. The current reconstruction with MAUS 0.9.2 gives the muon response in KL an unexpected shape. It may be as simple as the incorrect calibrations settings were used but if it is changes to the underlying reconstruction code could the experts please take a look and see what has changed?

I have attached the error log when I run we these flags set. Is this a CDB issue?

TOF_calib_date_from = '2011-12-03'
TOF_cabling_date_from = '2011-12-03’
KL_calib_date_from = ‘2011-12-03’


Files

error_log.txt (2.07 KB) error_log.txt Nugent, John , 23 February 2015 17:50
muonbeam.png (10.1 KB) muonbeam.png Nugent, John , 24 February 2015 11:55
muontemplate.png (9.18 KB) muontemplate.png Nugent, John , 24 February 2015 11:55
piontemplate.png (9.18 KB) piontemplate.png Nugent, John , 24 February 2015 11:55
PID_CM35.pdf (1010 KB) PID_CM35.pdf Orestano, Domizia, 24 February 2015 15:17
new_tofcalibTW.txt (10.2 KB) new_tofcalibTW.txt tof tw calibration -- from MB's branch Rajaram, Durga, 25 February 2015 15:35
new_tofcalibTrigger_trTOF1.txt (1.37 KB) new_tofcalibTrigger_trTOF1.txt tof trigger calibration -- from MB's branch Rajaram, Durga, 25 February 2015 15:35
new_tofcalibT0_trTOF1.txt (4 KB) new_tofcalibT0_trTOF1.txt tof t0 calibration -- from MB's branch Rajaram, Durga, 25 February 2015 15:35
3407-local-tofcalib.log (2.31 KB) 3407-local-tofcalib.log log file from running with local calib files Rajaram, Durga, 25 February 2015 15:35
config-local-tofcalib.py (29.9 KB) config-local-tofcalib.py Rajaram, Durga, 25 February 2015 15:39
muontemplate.png (9.32 KB) muontemplate.png Nugent, John , 26 February 2015 12:10
muonbeam.png (10.2 KB) muonbeam.png Nugent, John , 26 February 2015 12:10
muonbeam.png (11.9 KB) muonbeam.png Nugent, John , 26 February 2015 13:51
muontemplate.png (10.3 KB) muontemplate.png Nugent, John , 26 February 2015 13:51
muonbeam.png (11.9 KB) muonbeam.png Nugent, John , 26 February 2015 14:46
muontemplate.png (8.78 KB) muontemplate.png Nugent, John , 26 February 2015 14:46
analysis_script.py (18.9 KB) analysis_script.py Nugent, John , 09 March 2015 19:41

Related issues

Related to Analysis - Support #1473: Pion Contamination Paper ProgressClosedOrestano, Domizia21 May 201421 October 2014

Actions
#1

Updated by Rajaram, Durga over 7 years ago

~ August 2014, the default tof calibration retrieval was changed to get calibrations by run-number.
Earlier the default was "current" and one had to change TOF_calib_date_from to set the time period from which one wanted the calibrations.
In other words, if you process real data now with the default ConfigurationDefaults, you will get the calibrations corresponding to the run number being reconstructed.

To change the default behavior, you can change the flag

TOF_calib_by
to
"date"
instead of the (default)
"run_number"

When using the date, you need to set the

TOF_calib_date_from
flag in a format described in configuration defaults: line 536
date can be 'current' or a date in YYYY-MM-DD hh:mm:ss format

e.g.

TOF_calib_date_from = '2011-12-03 12:34:56'

The date specification format holds for the
TOF_cabling_date_from
and
KL_calib_date_from
flags

Your date format specification is incorrect and hence the "error". I will modify the error-trapping to return a more meaningful complaint if the format is incorrect.

#2

Updated by Nugent, John over 7 years ago

Thanks Durga I have updated my flags and the jobs runs without complaint. I am re-running the jobs just now and I'll let you know what the output looks like.

Cheeers,
John

#3

Updated by Nugent, John over 7 years ago

I have rerun the reconstruction with the correct calibration and cabling info with the same result as before. The new reconstruction gives different distributions to the one used in the original anaylsis. Domizia and Mariyan's suspicions were correct the TOF distributions are different with the new recon. I have attach three plots showing the TOF distributions with the old and new recon. The muon template has an offset in the latest version. Durga do you know of any changes in the TOF which could account for this?

Cheers,
John

#5

Updated by Rajaram, Durga over 7 years ago

John -- the TOF reconstruction has not changed in a long time.
It's hard to tell what's going on without knowing what reconstruction code was used earlier, what cuts (if any), and what calibrations.
Do we have any idea?
Can you give me a sample run #?

#6

Updated by Nugent, John over 7 years ago

I have asked Mariyan and others but I have not got a clear answer - I don't know what version of MAUS was used to reconstruct the old data. Perhaps Domizia remembers? I terms of cuts are you referring to the cuts in the reconstruction? I have run the standard analyze_data_offline.py over the raw data from http://gfe02.grid.hep.ph.ic.ac.uk:8301/MICE/Step1/
I have not changed any of the parameters for this job from the default. The calibration I used was from the CDB for the date of the run 03-12-2011. I am currently re-running with the calibration from the local MAUS files to see if that makes any difference. As I did not reconstruct the old data some input is required from the people involved in the original analysis perhaps Mariyan or Domizia can answer some of these questions? The run that I am looking at right now is 3253 but I see similar issues with 3256 and 3250.

Cheers,
John

#7

Updated by Orestano, Domizia over 7 years ago

Hi, I found my slides from CM35 which contain some information on the software version and code used for the first data processing, I attach them
Domizia

#8

Updated by Bogomilov, Mariyan over 7 years ago

Hello all,

honestly speaking I am surprised that for data analysis we are using the old ntuples, produced with standalone program. This is indeed ver.0.1.0 of MAUS (as pointed out in Domizia's presentation). My impression was that we compare data and MC done with recent versions (after 9.0). This why I said to you John, you should know better which version is used. I was always thinking you reprocessed data with recent MAUS versions and this is what I see on plots you show (what a mistake :().
Now I can confirm that there is difference in TOF calibrations between ver 1.0 and later (say 9.0). I have seen that some time ago. I spoke with Durga (do you remember, Durga, this conversation?) about this difference and it seemed that the reason is the slightly different distance between TOF stations used for calibration in two cases. Which distance is correct is unknown.
Concerning KL software - there is also changes between v.0.1.0 and 0.9.0, but I don't thing that they will change significantly KL response.
In conclusion - my opinion is that we should use the same reconstruction software for MC and data. We should not compare something produced with ver. 0.1.0 with another produced with ver. 0.9.0. I thing that this is the correct way of doing the analysis.

Mariyan

#9

Updated by Nugent, John over 7 years ago

Thanks Mariyan, could you point me to the correct TOF and KL calibration to use for the 2011 data or at least where I can find both? Clearly the one that I am running with at the moment is not giving the correct result. If I run with the correct calibration then we can at least disentangle the two problems. If the TOF plots are consistent then whatever has changed in the KL code is the issue.

Cheers,
John

#11

Updated by Nugent, John over 7 years ago

I have run with the file you posted Mariyan and I get the following error:

Error in TOFCalibrationMap::LoadT0File : Error during loading.
corrupted TOF Channel Key
Traceback (most recent call last):
File "/data/neutrino04/common_SW/MICE/maus-v0.9.2/src/common_py/ErrorHandler.py", line 159, in HandleCppException
raise CppError(error_message)
ErrorHandler.CppError: Failed to initialize calibration map at MapCppTOFSpacePoints::_process

This is with MAUS 0.9.2 are there some sort of compatibility issues with calibration files between MAUS version Durga?

Cheers,
John

#12

Updated by Rajaram, Durga about 7 years ago

John,

I don't see any problem using the files Mariyan pointed to.
Did you set the

TOF_calib_source
to
file
instead of "CDB"?
I have attached the configuration file I used, and for completeness, the files I got from Mariyan's branch.
I ran against a few events from run 3407.000 without any issues -- log attached.

#13

Updated by Rajaram, Durga about 7 years ago

  • File deleted (config-local-tofcalib.py)
#15

Updated by Rajaram, Durga about 7 years ago

I have attached the configuration file I used, and for completeness, the files I got from Mariyan's branch.

Uploaded the correct configuration file I used -- pointing to the calib files pulled from Mariyan's branch

#16

Updated by Nugent, John about 7 years ago

Thanks Durga, it was as simple as the calibration file having some whitespace at the end which caused the error. I have uploaded several more plots from running with Mariyan's calibration files. There is now better agreement between the TOF plots though small discrepancies remain. Unfortunately the difference in the KL spectrum remains. Whatever is causing the difference is not the TOF calibration. Calibrations for the KL are also required. I am using the local MAUS file for this at the moment. Which file did you run with when performing the original recon Mariyan? It was also mentioned that small changes to the KL code were made could these have affect the results?

Cheers,
John

#17

Updated by Karadzhov, Yordan about 7 years ago

John,
Can you please add the histogram stats to the plots comparing the new and the old data.
Thanks,
Yordan

#19

Updated by Karadzhov, Yordan about 7 years ago

I am sorry, my previous post was misleading. I would like to see comparison between the stats of the new data and the old data. In particular, I would like the see if the number of events is the same

#20

Updated by Nugent, John about 7 years ago

Is this more useful Yordan?

#21

Updated by Nugent, John about 7 years ago

Following your suggestion yesterday Durga I implemented the cuts I found in Mariyan's deck. Imposing the condition that the is only one spaceport in TOF0 and TOF1 does not change the TOF distributions however it does modify the KL distribution. There is now better agreement for the muon template discrepancies remain for the muon beam. Is there any word on that calibration file Mariyan?

Cheers,
John

#22

Updated by Bogomilov, Mariyan about 7 years ago

Yes, I spent some time in archaeology. You should disable gain kl correction, i.e. in ConfigurationDefault.py set

Enable_klgain_correction = false.

At that time all KL pmts were with equal gain, later they were changed. My expectation is that center of KL peak distribution will remain, but the peak will become broader when gain correction is switched off.
On part of KL I don't trace any other differences. But I see that between these two versions of the software data structure has been changed, which implies major differences on the level of coding. How or whether this will affect data distribution I don't know.

Cheers,
Mariyan

#23

Updated by Nugent, John about 7 years ago

Thanks for the info Mariyan, setting

Enable_klgain_correction = false.

improves the agreement in the muon beam but it is still not good enough. As far as I can see the TOF and KL calibration and cabling are set as in the original recon. I implement the cuts as in the original recon with no. of spacepoints in TOF0 & 1 set = 1 and no. of cell hits in KL > 0. Durga has confirmed that the TOF code has been stable for a long time and Mariyan believes that changes have been made the KL code in the data structure. Durga can you comment, are the changes to the data structure liable to change the output of the KLcellhits mapper? Is there anything else that could be contributing?

Mariyan is it possible that the cuts could have been applied differently for different runs in the original recon? If I impose the above conditions I get excellent agreement for the muon template but bad agreement for the muon beam. Then if I do not apply the cuts I get excellent agreement for the muon beam and bad agreement for the muon template. Do you have any job logs for those runs or anything that could help us understand this?

Cheers,
John

#24

Updated by Bogomilov, Mariyan about 7 years ago

Hello all,

sorry for late reply. I was off for couple of days.

Unfortunately I do not keep any logs for old data, but I believe that no other cuts are applied in producing root files.

Concerning data structure - there is misunderstanding - change of data structure affect whole MAUS incl. TOF. It is not only KL. To my knowledge (correct me if I am wrong) no one compared in deep ( i.e. in terms of distributions) the difference between old and new data structure neither in TOF nor in KL. Again, apologies if I am wrong.

John if you wish, post the script which you are using for producing root files and the code you are using for plotting the distributions. I will have a look and eventually will go in the past and will compare with old stuff in more details. Perhaps this is waste of time...

Cheers,
Mariyan

#25

Updated by Rajaram, Durga about 7 years ago

Durga has confirmed that the TOF code has been stable for a long time and Mariyan believes that changes have been made the KL code in the data structure. Durga can you comment, are the changes to the data structure liable to change the output of the KLcellhits mapper? Is there anything else that could be contributing?

I don't see how the changes to a datastructure would affect one distribution more (or less) than another.
I've been going through the revision histories and the only changes I see in the TOF reco since 0.1 are in the initialization of charge, and in the datastructure.

Since ~ MAUS-v0.7 we have been running an integration test -- runs tof reconstruction on a sample data file and compares the output distributions to the "reference" and it has not flagged any changes at least since then.

Do you have access to the lower level reconstruction objects from the old processing? Have you compared those? e.g. TOF digits, KL hits

Similar to what Mariyan said, I can try resurrecting an old MAUS and do a quick check [ [ if I can build it ]

#26

Updated by Nugent, John about 7 years ago

I do not have access to any of the lower level reconstruction objects in the old data. Mariyan do you have any of this information lying around?

#27

Updated by Bogomilov, Mariyan about 7 years ago

Me neither. The algorithm is very simple and fills only tof0 time, tof1 time and kl_product.

Also available in: Atom PDF