Home » R3BRoot » Simulation Issues » Question on R3BNeutronTracker2D (Question on R3BNeutronTracker2D)
Question on R3BNeutronTracker2D [message #19362] |
Thu, 07 July 2016 15:17 ![Go to next message Go to next message](/theme/gsi/images/down.png) |
C. A. Douma
Messages: 88 Registered: September 2015 Location: Groningen
|
continuous participant |
From: *kvi-cart.rug.nl
|
|
Sometimes I get not enough neuthits in the output.
I know that the neutron tracker applies the cuts from the
calibration files at lines 267-300 and then stores the
number of tracks that have to be reconstructed in the variable
nNeut. nNeut is also filled in the histogram h_ntracks.
However, if I let the neutron tracker run
(TGeant4, Ca48 with 500 AMeV on C-target & GLAD-field on),
then neuthit.@size and h_ntracks do not match at all. @size is smaller.
Can anyone explain me why the neutron tracker sometimes has less tracks?
I did find that if I skip the beta-window test in the AdvanchedMethod()
that this problem is solved, but then I get other problems in return...
Yours Sincerely,
Christiaan Douma.
|
|
|
Re: Question on R3BNeutronTracker2D [message #19363 is a reply to message #19362] |
Thu, 07 July 2016 17:00 ![Go to previous message Go to previous message](/theme/gsi/images/up.png) ![Go to next message Go to next message](/theme/gsi/images/down.png) |
Dmytro Kresan
Messages: 166 Registered: June 2004
|
first-grade participant |
From: *dyn.telefonica.de
|
|
Hi Christiaan,
How often does this happen, percentage of events?
Determining nNeut is just the first step in the reconstruction. nNeut is based on calorimetric and multiplicity properties of an event. Afterwards you need to find your candidates in the hit pattern. Imagine you did 3n -> 4n misidentification, then most probably program will find only 3 best candidates, so @size < nNeut. And this can happen in 20 - 30% of events - depending on input and cuts.
How did you calculate the energy/clusters cuts for your simulation? You need to recalculate them for every different input, do not apply "standard" values.
In addition, beta cut is applied, to select neutrons with velocity close to beam. Due to finite resolution, this condition could also cut out good candidates.
You can investigate 2 things:
1) Determine your multi-neutron identification matrices, like was done for 132Sn input. In your case, you can define primary neutron by cutting on time and position of the MCTrack vertex - close to (0, 0,0,0). Then you will know your proper 2D cuts, efficiency and misidentification.
2) To study the reaction input - plot the velocity distribution of "primary" neutrons, and cut values on top of it. This will help to adjust the beta-cut for this physics case.
Best regards,
Dima
|
|
|
Re: Question on R3BNeutronTracker2D [message #19364 is a reply to message #19363] |
Thu, 07 July 2016 17:20 ![Go to previous message Go to previous message](/theme/gsi/images/up.png) ![Go to next message Go to next message](/theme/gsi/images/down.png) |
C. A. Douma
Messages: 88 Registered: September 2015 Location: Groningen
|
continuous participant |
From: *kvi-cart.rug.nl
|
|
Dear Mr. Kresan,
This happens for nearly all events. The tracker identified either 0 or 1 track (and 1/10000 events: 2 tracks). The zeros are understandable, since not every Ca48 reacts in the target.
Then it is bend away.
I re-calculated the cuts for this specific case. I also use different cuts for different number of hits in the VETO. I use the 0p cuts if no VETO fired, the 1p cuts if exactly one bar of the VETO fired (TOF<NeuLAND), and so on.
The cuts might not be completely ideal (as they would be with your method 1), but they do look quite OK to me.
If I understand both you and the code correct, then you first mark & sort the clusters based on whether they can come from elastic scattering or not. Then from the sorted & marked clusters, you simply take the starting positions as the neuthits, but only those that have not been used yet, pass the energy threshold & pass the beta test, correct? And if the elastic scattering test provides you with less marked clusters then nNeut, then you cannot reconstrcut nNeut tracks. This is the 20%-30% MisID that you were talking about. Am I correct?
But if so, then how relevant is this beta test? In my case most particles are from background, not from the target, so their beta will not be close to the beam.
What I also do not understand is, why does the code (line 509) read: if(TMath::Abs(beta-beamBeta) > (0.05*600./beamEnergy) && ic > 0) {
I would expect the beta-test to be a '<', not '>'.
And if I would have the beta's for my specific case to be for example between (from your suggestion 2) 0.7 and 0.75, then how would this translate in a better beta cut?
Christiaan.
|
|
|
|
|
|
|
|
|
Re: Question on R3BNeutronTracker2D [message #19375 is a reply to message #19372] |
Wed, 13 July 2016 14:32 ![Go to previous message Go to previous message](/theme/gsi/images/up.png) |
C. A. Douma
Messages: 88 Registered: September 2015 Location: Groningen
|
continuous participant |
From: *kvi-cart.rug.nl
|
|
Dear Mr. Kresan,
Thank you for sending me the documentation on the GitHub repository. However, in a few days
I will go on holiday for 4 weeks. I will not have time to set up this git environment before
I leave. May I therefore ask you to commit my changes? I have adapted the software to work
without the need of a VETO class, etc, so it can be committed right away.
I tested the compilation on the Dev Branch of 26 May, and it compiles without errors.
After testing the code on my own simulations, all I did were some changes in how
to collect inputs in the Init()-functions. It should therefore work during runtime as well.
The changes I made comprise the following:
1) Digitizer: coordinate transformations between local and global frames work OK now.
The user can also adapt energy thresholds & time resultions if he/she desires.
2) Clusterfinder: Clusters will now be merged if they touch/overlap. Cluster radius
in both space and time can also be set by the user now.
3) NeutronTracker: The beta-test (& the rest of the tracker) is now invariant under
global/local differences. The user can smanually set the beam start position and
the target position, so that Time Of Flight will now be computed only between
the target and NeuLAND (as it should be).
In addition, the tracker now automatically takes any number of energy cuts
specified in the calibration file. You are no longer bound to exactly 5 cuts.
Furthermore, depending on the number of hits in the VETO, the tracker can also
use a set of cuts for 1-5 neutrons, or a set for 1 proton + 0-5 neutrons, or a
set of 2 protons + 0-5 neutrons, etc. Multiple calibration files will be read
automatically and the right file is selected in each event based on the number of hits
in the VETO. The user has to specify an upper bound for the number of protons
(it is set to 0 by default) and calibration files up to this upper bound should
be provided. If the VETO digitizer ouput is not specified by and AddFriend-call,
the tracker will automatically revert back to the 0 proton case for every event.
Thanks in advance!
Christiaan.
|
|
|
Goto Forum:
Current Time: Sun Sep 01 16:05:19 CEST 2024
Total time taken to generate the page: 0.00664 seconds
|