No of stars and mgdraw output when LAM BIAS card is used

Dear expert,

I have some queries regarding number of stars. I have attached here one screenshot. Total number of inelastic interactions = 922.

I added one routine in mgdraw.f with following commands and got the same value 922. Here total history = 1E+6

  IF (ICODE .EQ. 100 .OR. ICODE .EQ. 101)THEN

Now, in the .out file, there is also another parameter total weight = 1.843960E+01.
(Note: I have used one LAM-BIAS card with lambda inelastic 0.02)

So per primary this value will be = 1.843960E-5 which is similar to the number Number of stars generated per beam particle.

In line with this, I feel the number I am counting as per the previous discussion Modify mgdraw.f routine - #3 by ceruttif will be influenced by the LAM bias card.

For e.g., with this same history (1E+6), for a reaction 116Sn(α,np)118Sb, I got no of neutrons produced via this channel = 34

But I feel, this is not a true value since LAM BIAS card has been used, so do I have to divide this value by total primary weight printed in .out file?



It depends on what you want to get.
If it is per interacting alpha, you have to divide your event-by-event counter by 922 (i.e., the total number of simulated inelastic interactions).
If it is per incident alpha, you have to divide it by 1E6 and multiply it by 0.02.

Thank you @ceruttif for the clarification. However, I have the following queries:

  1. Will it be 0.02 or 0.054 (i.e. 1/18.439) to be multiplied?

  2. Also, if I want to calculate weight of inelastic interaction via mgdraw.f routine, what is the associate variable name?

  3. Since I have used thin target, I assumed there will be some scattered alpha from elastic interaction. But the .out file has printed 0 value as total no of elastic interactions.

It will be helpful if you kindly clarify.



  1. 0.02, i.e. 18.44/922
  2. you do not really need any variable, rather to multiply the number of inelastic interactions by 0.02
  3. no nuclear elastic interaction is presently implemented for alphas (nor for ions heavier than deuterons, including the latter)
1 Like

Thank you @ceruttif for the clarification.

My concept regarding the use of number of stars is not very clear. I got some confusion.

Lets say,

Total number of inelastic interactions = Int
Total weight of the inelastic interactions = W
History = H

no of stars per beam particle = W/H

  1. For a nuclear interaction, if I want to calculate neutron dose at a particular location using USRBIN or want to score neutron flux by USRBDX, the result is in per primary, in such cases, we do not need to multiply by no of stars.

However, while using USRYIELD card, to plot double differential sigma, we are multiplying the result by no of stars, i.e. W/H
What is the reason for this? Also, if we score double differential N instead of sigma, do we also have to multiply the result by no of stars (W/H)?

  1. Now say, LAM Bias is used. We are using USRYIELD card. To plot double differential sigma, we are still multiplying the result by no of stars, i.e. W/H.

But when mgdraw.f is used to count no of neutrons, we are multiplying the result by W/(H*Int)

Can you please guide to understand the doubt?



This is because here you want to (exceptionally) obtain a microscopic cross section. Thereby, based on the knowledge of the reaction cross section (which is the embedded multiplication factor, linked to the inelastic interaction probability), you need to get a yield per reaction (star, and not per incident particle), to be multiplied by the reaction cross section.
By the way, note that you need to divide (and not multiply) by the number of stars per beam particle, namely the star probability.

Here, again, it depends on what you are interested in. For normal applications, you may be interested in the yield per incident particle, as naturally provided by USRYIELD. But if you aim to transform this into a microscopic cross section (when it makes sense, i.e., for a thin target), then we are back to the above.

  1. The reason is pretty obvious (filtering the reiterated multiplication vs division mistake): USRYIELD takes automatically into account the biasing factor, which mgdraw has to leave on user coding responsibility.

Dear @ceruttif

Thank you for explaining it in details.