Dear FLUKA expert,
I calculate the Almighty peak detection efficiency of HPGe for 60Co by using DETECT card and the result is 2.25%.But the experimental value is 0.94%. Then verify it with MCNP5 and I got the efficiency is 1.2%. Because there is no detailed simulation of the detector’s structure, we only have the approximate size of the detector, I think the result of MCNP5 is reasonable, the result of FLUKA is inaccurate. What caused this situation?Is there any way to change the result?HPGe.inp (3.7 KB)
Dear @shusheng
First, some input cleanup.
-
I would suggest that you check whether you really need all the MAT-PROP and STERNHEIMer cards. If they were simply added when importing from the Flair material database and you are not changing the values, then they are not necessary.
-
You could also live without the EMFCUT card for the particular problem. It will only make your simulation slower without particular gains in accuracy with respect to the PRECISIOn DEFAULT. In any case, a 1 eV threshold is way too low for FLUKA (go down to 1 keV if you must).
To the main issue: given the close distance of the source from the detector window (2.1 cm), the summing correction for the 1173 and 1332 keV lines of Co-60 is likely significant. Has the experimental result been corrected accordingly?
Also: have you in fact manipulated the material properties via MAT-PROP/STERNHEIMer? I suspect not, but let us know.
Dear Andrea Tsinganis,
Thank you very much!
1.As you said, I don’t actually need the MAT-PROP, STERNNHEIMER and EMFCUT card. So I delete them, but the result has not changed.
2.Even if I did the correction, the true summing coincidence factor is about 1.05, there is a big gap between the experimental data and simulated data.
I think the activity of the radioactive source may and the distance between source and detector may be inaccurate(the experiment data is from others). I will experiment by myself.
Yes, I did it. Is there any problem?
Dear @shusheng
Yes, those additional cards were not expected to change the result, it was just to clean up the input and speed up the execution.
Especially in a close geometry, small changes in the distances can have a big impact. An absolute comparison of HPGe detector efficiency may require significant fine tuning of the geometry, including the distance between the detector window and the crystal (not always known accurately), and even the crystal dead layer. The accuracy of the experimental result is of course up to you to judge; even there, the accuracy of the sample position and efficiency characterisation is crucial.
What remains more puzzling is the discrepancy between the FLUKA and MCNP results. Were these obtained with exactly the same geometry (e.g. by importing/exporting the geometry via Flair) or were these independently constructed models? Also, is the scoring comparable? Were other physics settings consistent?
These are just some ideas, it could be worth that you compare the two inputs, perhaps stripping them down to the minimum requirements and comparing the results again (once the geometry and source definitions are consistent).
Dear Andrea Tsinganis,
The geometry in MCNP is exporting from FLUKA. But the way of beam’s definition is different. In FLUKA, I use an isotope source, but I need to enter the source’s energy and branch ratio. I set p(photon) e(electron)mode in MCNP, and I use ELPT card(1keV) in MCNP5.
Dear @shusheng
Good, if the MCNP geometry is exported via Flair then that part should be under control.
The different implementation of the sources is of course significant. My suggestion in order to try to isolate the cause of the difference would be to set up a monoenergetic, isotropic photon point source in both codes (e.g. the 1173 keV line), taking care to define exactly the same position. Also, don’t apply any peak broadening in MCNP and make sure you have equivalent scoring (energy deposition spectrum, with the DETECT card in FLUKA and -I guess- an *F8 tally in MCNP).
The ELPT card, setting a 1 keV cut-off in some specific cell (the crystal?) is probably not relevant for the problem, you could deactivate it for the time being. In general, keep minimal inputs in both codes for this comparison.