Dear professors,
I’m searching for all possible neutron captures on nucleus. My logic is to go through all low-energy neutron reactions (IFLAG = 3 in mdstck.f) with JTRACK = 8 and without KPART(IP) = 8 and record relative information. The problem occurs when I compare my result with G4 simulation. The number of neutron captures is ten times larger than that of G4. So, I’m wondering if my code is wrong or incomplete. I noticed that some of above generate gammas as secondaries and some don’t. Are neutron captures necessarily accompanied by gamma generation?
By the way, as I have included resnuc.inc in mdstck.f, I want to confirm that ICRES and IBRES are the properties of the nuclei after reaction?
Best regards,
Hechong Han
mdstck.f (2.3 KB)
muon.txt (166.4 KB)
newsource.f (7.3 KB)
Te-LS.inp (3.4 KB)
Dear @hanhechong,
Thanks for your queries.
- Why are you only applying the point wise treatment to the Tellurium?.
Remember that, as it’s said in the note 3 of the manual:
Mixed materials can co-exist where some elements are treated point wise and some multi-group wise. This can be fine-tuned by the user mainly for computational speed purposes. Despite that is not really necessary since the new pointwise treatment adds some penalty in CPU time however with superior physics results.
I would recommend you to leave the LOW-PWXS empty to apply this treatment to all the materials
- Are you interested only in the neutron captures in the “LS” region?
If this is the case, be careful because your neutrons are interacting also with the the other regions.
-
Regarding your question:
Are neutron captures necessarily accompanied by gamma generation?
Yes, in general you should observe the gamma emission + the nucleus recoil. In your problem you can observe in many cases the following
What is it? A neutron captured, and the generation of a gamma and a deuteron as secondaries.
It seems that the mdstck routine considers also the elastic cases, this is the reason why you can also observe these cases:
Where you have the recoil of a carbon nucleus.
I want to confirm that ICRES and IBRES are the properties of the nuclei after reaction?
I confirm you, and the FLUKA documentation in resnuc.inc as well:
-
I would say that if you just filter the cases where there is a gamma generation and a nucleus recoil, you can estimate the number of neutron captures.
-
Related to the comparison with G4, first try to check if you observe any difference with this considerations, and if you still have this factor 10. Multiple reasons could generate this discrepancy , but that’s a topic to discuss later.
Cheers,
Have a nice weekend,
André
Dear @adonadon ,
Thank you for your excellent explanation! I have modified the input according to your suggestions. Now I understand that a neutron capture should be associated with both gamma emissions and residual nucleus. I still have some detailed questions concerning this topic.
-
I used AGESEC(IP) to record the time of gamma emissions with respect to the time of inelastic or low-energy neutron reaction(IFLAG = 1 OR IFLAG = 3). In my opinion, the deexcitation of the residual nucleus should have taken some time. Why are the results always zero?
-
I noticed that when a typical neutron capture occurs, there will be no outcomes for ICRES, IBRES and ISMRES. The nuclei is considered as a recoil nuclei in KPART(IP) instead of residual nuclei. But I also observe considerable events that both of above are non-zero and consistent. The reaction type is still low-energy neutron but without gamma emissions and other products. What could it possibly happen in these cases? It seems like elastic scattering but the IFLAG does not equal to 2. The following is just an example.
(n,0) 3 3.945E+03 -1.958E+03 2.999E+03 8 16 0
(n,0)parent 8
(n,0)others -801607
- A small amount of inelatic scattering are also recorded. Some of them have the same properties as the typical neutron captures (gamma emissions and recoil nucleus). I wonder if they should also be involved.
(n,0) 1 2.475E+03 1.864E+03 -2.244E+03 0 0 0
(n,0)parent 8 4
(n,0)gamma 6.881E-03 0.000E+00
(n,0)others -501107
(n,0)others -6
(n,0)others -3
- At last, there are some strange cases in neutron inelastic scattering. All the information mentioned (residual nucleus, recoil nucleus, gamma emissions and other products) are missed. The manual says that
MDSTCKis called after a nuclear interaction in which at least one secondary particle has been produced. But there is no KPART(IP). How could it possibly react?
(n,0) 1 -1.114E+03 1.407E+03 -3.270E+03 0 0 0
(n,0)parent 8 0
I have uploaded the updated input and mdstck.f. Thank you for your help!
Best regards,
Hechong Han
mdstck.f (3.4 KB)
Te-LS.inp (3.4 KB)
Dear @hanhechong,
I apologize for the delayed response.
-
- It is correct, the deexcitation of the residual nucleus takes some time, but in mdstck, in AGESEC(IP) you have the prompt gamma radiation generated from the neutron capture, which is emitted basically immediately. For the gammas generated from the decay of the radioactive isotopes (delay ones), you can filter in USDRAW with ICODE = 110, obtaining the radioactive decay products and the correspondent time of emission.
-
As mentioned in my third comment:
“It seems that the mdstck routine considers the elastic cases as well, which is why you can observe these cases…”
-
No, as defined earlier, we consider a neutron capture when there is emission of gammas and a recoiled nucleus. In this case, what you are observing is an inelastic interaction of a gamma impacting an oxygen nucleus, resulting in the observation of boron, deuteron, and 4-He.
-
Lastly, the reason you are observing these cases is because you are using the NP variable instead of NPSECN, which is more appropriate as it stores information about all the secondaries generated in the process. For your purposes, you should observe NP=NPSECN, which is usually the case. However, there are some decay processes that produce these situations. If you replace all instances of NP with NPSECN, you will observe that these cases are not neutron captures. I still need to investigate further to determine their origin.
I will inform you as soon as I identify the source of these processes. In the meantime, I believe you can effectively filter all neutron captures using the information provided here.
Best,
André
Dear @adonadon ,
Thank you again for your excellent explanation! Actually, with your help I have already succeeded in recording all the neutron captures. My further questions above and followed are just for more accurate understanding.
- I want to combine your point 1 and point 4 to discuss all the secondaries including delayed gamma emissions. Firstly, a quick question about NP and NPSECN that is NP more general and NPSECN more specific for mdstck.f? Therefore, using NPSECN is a more accurate way to record. What’s the difference between these two in other user routines? Secondly, as I have substituted NPSECN for NP, the exact complement information for the case in my point 4 above has been revealed. But the results for low-energy neutron(IFLAG = 3) does not change. It seems that for low-energy neutron reactions, the prompt and delay secondaries are considered as two different processes (as you said I have to filter the latter process in mgdraw.f with ICODE = 110). However, in inelastic scattering, the two processes are considered as one in the following example. My third question is that where is the nuclei that is scattered with this neutron and later decays?
(n,0) 1 -1.114E+03 1.407E+03 -3.270E+03 0 0 0
(n,0)parent 8
(n,0)gamma 1.779E-03 2.842E+01
(n,0)others 3
(n,0)others 6
- As for your point 3, the parent is neutron and gamma is the secondary. Why do you interpret it as a gamma impacting an oxygen nuclei?
Thank you for your help!
Best regards,
Hechong Han
Dear @hanhechong,
I’m glad you managed to achieve the goal.
First, about the point 2, it was a neutron, not a gamma (my bad! 
)
Regarding the point 1, NP is the variable associated to the number of secondaries generated in the last hadronic event. From FLUKA documentation:
While NPSECN is provided directly to the MDSTCK routine, with the exact number of secondaries generated for the current process.
Still, I need further inverstigation to give you more details about this.
I’ll come back to you as soon as I understand this better.
Have a good day,
André