Added by Rajaram, Durga over 9 years ago.
Updated about 9 years ago.
07 February 2014
Need simulation of KL detector in MAUS.
- description exists in legacy geometry
- are the material definitions and internal geometries correct?
- there is some legacy code for the sensitive detector in src/legacy/DetModel/KL/ -- needs to be checked/modified
- add KLChannelId and typedef KLHit [ src/common_cpp/DataStructure ]
- add KLChannelIdProcessor [ src/common_cpp/JsonCppProcessors ]
- digitize GEANT hits - add src/map/KLMCDigitizer
- check data structure [ src/common_cpp/DataStructure/KLDigit.xx ]
- reconstruction code exists
- the reconstruction [ MapCppKLCellHit ] should treat MC digits same way as it does digits from real data
- unit tests
- integration tests to validate simulation+reconstruction chain
The KL digitizer crashes on some events:
python bin/user/simulate_kl.py --simulation_geometry_filename=Stage4.dat
Full log attached.
#6 0x00007fe9b0882345 in MAUS::MapCppKLCellHits::fillCellHit(Json::Value, Json::Value) () from /home/durga/trunk-debug/build/_MapCppKLCellHits.so
#7 0x00007fe9b08831cc in MAUS::MapCppKLCellHits::makeCellHits(Json::Value) () from /home/durga/trunk-debug/build/_MapCppKLCellHits.so
#8 0x00007fe9b0883ac6 in MAUS::MapCppKLCellHits::process(std::basic_string<char, std::char_traits<char>, std::allocator<char> >) () from /home/durga/trunk-debug/build/_MapCppKLCellHits.so
#9 0x00007fe9b0888d77 in _wrap_MapCppKLCellHits_process () from /home/durga/trunk-debug/build/_MapCppKLCellHits.so
#10 0x00007fe9c92aa894 in ext_do_call (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4323
#11 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2705
The crash is happening because of a division by zero in MapCppKLCellHits, line: 210-211
xDocCellHit["charge_product"] = 2 * xChargeDigit0 * xChargeDigit1 / (xChargeDigit0 + xChargeDigit1);
I fixed this by setting the charge_product to 0 if (xChargeDigit0 + xChargeDigit1) == 0
I'll push that if you think that's reasonable.
The question though is why the MC digitizer is giving some digits of 0 -- very low energy deposit+smearing round down?
please push it. I was not able to investigate it until now. I'll try to see what is going on in details.
Ok great, thanks!
FYI, if you find it useful, I have attached some plots from naive quick simulations I ran
Also available in: Atom