Timing Correction for MuonDIS generation #510
Conversation
anupama-reghunath
force-pushed
the
MuonDIS
branch
from
882f31d to
924ee69
Compare
There was a problem hiding this comment.
Very nice improvements. Generally looking good, but some nitpicks.
Once all other issues are resolved, it would be good to run clang-format and ruff over the touched code.
I would suggest fixing issues with --fixup commits, and then at the end we can do a rebase and automatically squash the fixes.
You might want to check out git-absorb to make that process a bit simpler.
Could you add some explanation to your first post, maybe with the before/after plots you sent me? |
|
This change would also benefit from a description in the CHANGELOG (probably an entire paragraph!) |
|
@maksymovchynnikov Could you please have a look and ideally test these changes? It would be good to merge these ASAP. |
|
@maksymovchynnikov Your monthly reminder that your feedback would be very welcome on this pull request. |
|
@anupama-reghunath I also noticed that there are still a lot of open comments. |
anupama-reghunath
force-pushed
the
MuonDIS
branch
from
d4564d6 to
2fe2bea
Compare
Added array for softTracks for MuDIS
anupama-reghunath
force-pushed
the
MuonDIS
branch
from
eb036ca to
908e32a
Compare
|
@olantwin I have addressed the open comments. Can you please let me know if anything else is needed? |
| if args.path: | ||
| path = args.path | ||
| else: | ||
| path = "/eos/experiment/ship/simulation/bkg/MuonBack_2024helium/sc_v6_10_spills" | ||
|
|
There was a problem hiding this comment.
Why not handle this by giving --path a default value?
There was a problem hiding this comment.
Better readability.
There was a problem hiding this comment.
I don't see how this improves readability, and like this the default value is not visible in the --help output
|
For any new code, we should not use TVectorD anymore, I'll make an exception for this PR, as the muon DIS was already using it. We should consider refactoring to use STL containers. |
muonDIS/makeMuonDIS.py
Outdated
| # dPartDIS.ConstructedAt(nPart).Use(part) #to be adapted later | ||
| dPartDIS[nPart] = part | ||
| if itrk == 1: | ||
| with open(f"sigmadata_{args.nJob}.txt", "a") as fcross: |
There was a problem hiding this comment.
Reasoning for having an external textfile to save the DIS cross section from Pythia6:
- As is, the DIS cross section otherwise is not saved anywhere
- Consider generating N >>1 DIS events for the single muon. Since Pythia generates the cross-section value events-by-event, it converges from some meaningless value for the 1st event to the proper value for the Nth event. In the proper implementation, all the events must share the same correct cross-section. As a temporary fix,we achieve this by reading the Nth DIS cross section entry for a given muon to calculate the weight.
There was a problem hiding this comment.
My plan of action to avoid this external file is:
1.Directly write the cross section to the muonDis file ( which is passed as the input for muonDIS production)
2. Set weight of the scattered muon to the cross section in the simulation (atm both the incoming and scattered have the same weight from the spill).
Perhaps also set a minimum value for the number of DIS per muon to allow for convergence?
Please let me know what you think! @olantwin
There was a problem hiding this comment.
Heres a sample from 200 DIS events per muon from a test sample. There is a reset at the halfpoint mark when the fixed target changes from proton to neutron.
There was a problem hiding this comment.
Ok, this is now much clearer, thanks!
I agree, that this information should be directly in the sample. Is there a weight field in the event header? Otherwise, using the weight of the scattered muon seems like an OK workaround (maybe we can preserve the weight of the incoming muon from the target sim).
We do not use the cross section anywhere else, right?
Could you prepare that plot also relative to the final cross section? That allow us to estimate a good default number of events to generate.
There was a problem hiding this comment.
I agree, that this information should be directly in the sample. Is there a weight field in the event header?
I couldnt find one in ShipEventHeader.
Otherwise, using the weight of the scattered muon seems like an OK workaround (maybe we can preserve the weight of the incoming muon from the target sim).
At the moment I save the cross section onto the scattered muon and also refactor the incoming muon's weight to include the DIS multiplicity such that we maintain the event weight's normalisation to a spill. Previously this refactoring was explicitly done in the analysis, but the meta data (nDIS per muon) needed to be explicitly plugged in to calculate weight for any sim file.
We do not use the cross section anywhere else, right?
Only when calculating the weight of the event. ( Done during analysis)
Could you prepare that plot also relative to the final cross section? That allow us to estimate a good default number of events to generate.
For 2000 DIS events, the convergence seems to be inversely correlated with the energy of the muon.
Removed Condor Process variable in makeMuonDIS.py
Attached are the SBT response plots produced for the previous MuonDIS(involving backwards travelling muons), and with the suggested corrections with the new MuonDIS. SBThits are color coded wrt to the time of DIS. New method preserves the incoming muon's time as well as its veto response, and ensures that the event is temporally consistent.
Before:
After: