MCNP5 LINAC Isocenter Dose Calculation Produces No Tally Results

[Anisur Rahman]

TL;DR

I am simulating a medical LINAC in MCNP5 and trying to calculate the absorbed dose at the isocenter, but my tally is not producing any meaningful results. I am looking for help identifying the problem with my source, geometry, or tally setup.

I am working on a Monte Carlo simulation of a medical linear accelerator (LINAC) using MCNP5. My objective is to calculate the radiation dose at the isocenter of the LINAC treatment setup.

I have constructed the LINAC geometry, including the relevant components of the treatment head, and defined an electron beam as the source. I have also defined a tally at the isocenter to estimate the dose delivered at that location.

However, after running the MCNP input file, I am not getting any useful tally data for the isocenter. The calculation itself appears to run, but the expected dose/tally result is zero (0).

I am particularly unsure whether the problem is related to:

• The definition or placement of the tally at the isocenter
• The source definition and electron beam parameters
• Particle transport through the LINAC head
• The choice of tally for calculating dose
• The energy binning or DE/DF cards
• The normalization of the tally
• The geometry/material definitions
• Particle importances or particle cutoffs

My main goal is to obtain the absorbed dose at the LINAC isocenter from the simulated electron/photon field.

I am using MCNP5. I have attached the complete input file, including the geometry, source definition, tally cards, and material definitions, if needed.

Could anyone help me identify what might be preventing the isocenter dose tally from producing a result? I would particularly appreciate advice on whether my tally setup is appropriate for calculating dose at the isocenter in a LINAC simulation.

 

[Choppy]

I'm not an MCNP user, but I've done some Monte Carlo simulations.
Some common things to consider/check:

• If you're simulating from the point of an electron source incident on your target, remember the bremsstrahlung process is not that efficient. How many histories are you running?
• Are you implementing any variance reduction techniques? If say one in every hundred incident electron produces a photon, depending on your geometry there's finite probability that said electron will be directed toward your phantom setup.
• What does your scoring volume consist of? Have you defined a water phantom at your isocenter? Or are you attempting to score dose in air?
• How large is your scoring volume?
• Does your output give you any error codes?

 

[Alex A]

I am not qualified in medical radiation physics. I assume this is an academic problem.

As written the input file contains elemental materials which are fine for scattering, but generate errors for photonuclear reactions. If you have the right libraries for this then using them is fine. I am struggling to find them and might try rewriting the input file in terms of isotopes to see if I can run the input file as intended.

When I run the file with default settings (I assume photonuclear processes are off), I get a result for total and non scattered F5 tally that is not zero. This is hopeful, but it rules out most of the input file as the problem.

You are using a DF card that seems to calculate equivalent Air Kerma in Sieverts (Anteroposterior position) from Grays. But the F5 tally does not output in Grays, it outputs photon flux in photons per square centimeter (per source particle). Where did your df5 line come from, please?

The cone on your collimator seems very wide, but this would increase the tally not block it.

10⁵ is not a lot of histories, and your detector is a 10cm radius point detector 1m from the target. But it still should not be producing a zero answer. Something sounds wrong with the way the input file is running, for example your libraries or some of the PHYS switches you are using. Careful reading of your output file is a good next step. If you are allowed, please attach a copy to the thread. When we've fixed the big problem, we can look at some of the others.