Hi Ben,
I hope Nicholas Ritchie will find this and fill in the gaps to my understanding. In the interim I will give it my best shot. The best source of information is the file:
http://dtsa2.svnrepository.com/DTSA2/trac.cgi/browser/NWMR/trunk/EPQ/src/gov/nist/microanalysis/NISTMonte/Gen3/PhiRhoZ3.java.
There are two types of normalization. The first seems to be what we are used to. In my experience it seems to match well with Casino and the older work from Castaing. First look at line 67: the mNorm coeficient is calculated using the bin width, the generated intensity, and difference in position (I'm gussing a depth.) This is used in the 4 functions between lines 77 to 91. The intensity functions seem to add the bin width back. There are a corresponding set of functions from lines 227 to 249 that operate on xray-transition objects.
I tried to check this on a standard system. The algorithm goes all the way back to 1955 (the year I was born): R. Castaing and J Descamps, J. Physique Radium, 16, 304 (1955) where he examined Cu in Al. Pouchou and Pichoir used this in Figure 7 of Chapter 2 in Heinrich and Newbury, Electron Probe Quantification. I digitized the data and did a DTSA-II MonteCarlo simulation and then processed the data in R.
The file 'Castaing-Cu-in-Al' is the original. I digitized the points that the authors published. I then compared this to the output from DTSA using both the Emit_Cu_K_L3 and the Emit_I_Cu_K_L3. The plot Castaing-Cu-in-Al-Phi-Rho-Z.png show excellent agreement. The version with the intensity version had much higher values (Castaing-Cu-in-Al-Phi-Rho-Z-I.png).
The Monte Carlo version is quite important for multilayer simulations where it is really hard to work in rho-z space. That's why DTSA-II reports in Z-space. I'd really like some well characterized data sets to work through this. I don't have any I really trust. I previously noted that I get great agreement with DTSA using K-L3 transitions. I get big deviations in intensity with, for example, the Zn L3-M5 transition when I simulate ZnO. I reported this to Nicholas Ritchie last June at Lehigh. He has been really busy and I have not heard back regarding this. Debugging this issue is beyond my skills.
I think DTSA is incredibly important to the community (along with CalcZAF) because both are Open Source. I can examine the algorithms. I can (and have) suggested updates for DTSA and Nicholas has graciously incorporated them. I especially like the Jython scripting language because I can make my analyses truely reproducible.