Probe Software Users Forum
Software => CalcZAF and Standard => Topic started by: Probeman on March 09, 2014, 03:17:26 PM
-
Chad Parish asks:
I've recently found a very nice parameterization of K-shell electron-impact ionization cross-sections (Talukder et al., Int. J. Mass Spec., V269 (2008) P. 118 and V309 (2012) P. 212) which are very convenient to code into the computer.
I'm not finding similar good (or even fair) parameterizations for L or M-shells. Can anyone recommend good references from which to write code for X-ray cross-sections?
Xavier Llovet responds:
...might be interest in the attached paper. The complete cross section database will be available from NIST very soon (I'll let you know when). If he's interested in an analytical paramaterization, then Fortran subroutines are available from the on-line version of Ref.[31] (Bote et al. ATNDT 95, 871-909, 2009). As easy as it gets.
http://scitation.aip.org/content/aip/journal/jpcrd/43/1/10.1063/1.4832851
-
Chad,
For modeling thin films in for TEM at 80 to 300 keV you'll want to check this topic also:
http://probesoftware.com/smf/index.php?topic=57.0
To extract the k-ratios from the Penepma calculations I suggest using the "Batch Mode" dialog as seen here:
(https://probesoftware.com/smf/oldpics/i62.tinypic.com/2rpxv0g.jpg)
and have all your calculations saved automatically as seen here (for a slightly different example):
(https://probesoftware.com/smf/oldpics/i61.tinypic.com/33jtox1.jpg)
Finally, to *manually* extract your intensities to create k-ratios, see this post here:
http://probesoftware.com/smf/index.php?topic=59.msg221#msg221
The above link is best for understanding the gritty details, but the next post describes a new feature which allows one to simply specify the element, x-ray, a folder containing the standard intensity and the folder containing the unknown samples (a separate sub folder for each Penepma batch run).
Easy!
-
Here I describe a new feature which allows the user to simply specify a few parameters and the program will automatically extract k-ratios from multiple Penepma batch runs...
Starting from the Penepma Batch Mode window as seen here:
(https://probesoftware.com/smf/oldpics/i59.tinypic.com/apjy1y.jpg)
specify the element and x-ray to extract k-ratios for and click the Extract K-Ratios button. The program will then ask for two folders, the first for the folder containing the (usually bulk geometry) standard intensity calculation from Penepma for that element as seen here:
(https://probesoftware.com/smf/oldpics/i60.tinypic.com/s62gsm.jpg)
Note that the current standard intensity folder containing the pe-intens-01.dat file is empty (indicated by the two closed parentheses), and the program first starts in the C:\UserData\Penepma12\Batch folder to begin with. Therefore the user must browse to the actual folder containing the standard intensity file as seen here:
(https://probesoftware.com/smf/oldpics/i58.tinypic.com/2cs991y.jpg)
Next the program will ask for the folder containing the unknown samples, and again it will start in the C:\UserData\Penepma12\Batch folder to begin with, so again, the user must browse to the actual folder containing the unknown intensities as seen here:
(https://probesoftware.com/smf/oldpics/i57.tinypic.com/2usudk8.jpg)
After specifying the unknown intensity folder (which contains sub folders created by the Penepma batch mode), the program will automatically output the calculated k-ratios for all samples to a tab delimited text file which can be edited further as necessary. An example of the output is shown here and attached below:
(https://probesoftware.com/smf/oldpics/i58.tinypic.com/r0ba7p.jpg)
Note that if the user clicks the Extract K-ratios button a second time, the application will start at the last folder specified as seen here:
(https://probesoftware.com/smf/oldpics/i61.tinypic.com/34g69s5.jpg)
-
A new method for Penepma compositional input has been added as seen here:
(https://probesoftware.com/smf/oldpics/i60.tinypic.com/c3xhv.jpg)
Using this method one can specify a "weight percent string" such as Fe1Ni99 to get 1 wt.% Fe and 99 wt.% Ni in a composition as seen here:
(https://probesoftware.com/smf/oldpics/i61.tinypic.com/i294b4.jpg)
To differentiate this compositional name from a "formula string" such as Mg2SiO4, the program will automatically append the string "_atom" to formula composition names and the string "_weight" for weight percent string names as seen here:
(https://probesoftware.com/smf/oldpics/i57.tinypic.com/2yx3nl1.jpg)
I should also mention that I have a number of pure elements calculated by Penepma at 10, 15 and 20 keV for use as standards for k-ratio calculations if anyone needs them.
-
As mentioned previously I have calculated a number of pure bulk element intensities at 10, 15 and 20 keV for use as standard intensities for typical Penepma k-ratio calculations. The current version of this ZIP file is here:
http://probesoftware.com/download/BulkPureElements.ZIP
It can be extracted to the Penepma folder (usually C:\UserData\Penepma12\Penepma), for example "C:\UserData\Penepma12\Penepma\BulkPureElements" and utilized in the above Extract K-Ratios button in the Penepma Batch Mode window.
Let me know if there are other pure elements we should pre-calculate and have available to save time...
-
A complete set of binary alpha factors is still being calculated, but the PAR files for the specific compositions in the POUCHOU2.DAT data set are complete and I thought I would show where we are so far...
Using the default JTA/Reed phi-rho-z as a starting point we get the following reasonable results:
(https://probesoftware.com/smf/oldpics/i60.tinypic.com/10igrhk.jpg)
Now using the Penfluor PAR files calculated for the specific compositions in the Pouchou data set, we obtain this result which includes a complete fluorescence correction with continuum:
(https://probesoftware.com/smf/oldpics/i61.tinypic.com/qqab6r.jpg)
Now, running the same calculation using the currently available binary PAR files and fitting them as a hyperbolic relationship we obtain this result:
(https://probesoftware.com/smf/oldpics/i62.tinypic.com/2d8eib.jpg)
Again, this is still using some phi-rho-z for the remaining uncalculated binaries, but it is showing promise!
-
Sheri Singerling at UNM has created an excellent document on how to run Penepma to obtain k-ratios to compare with experimental measurements and this can be downloaded here:
http://probesoftware.com/smf/index.php?topic=322.msg1641#msg1641
Note that although Sheri is absolutely correct on how to locate the appropriate x-ray intensities for producing your k-ratios, there is now an automated method if you would prefer which is described here:
http://probesoftware.com/smf/index.php?topic=202.msg1506#msg1506
-
As mentioned previously I have calculated a number of pure bulk element intensities at 10, 15 and 20 keV for use as standard intensities for typical Penepma k-ratio calculations. The current version of this ZIP file is here:
http://probesoftware.com/download/BulkPureElements.ZIP
It can be extracted to the Penepma folder (usually C:\UserData\Penepma12\Penepma), for example "C:\UserData\Penepma12\Penepma\BulkPureElements" and utilized in the above Extract K-Ratios button in the Penepma Batch Mode window.
Let me know if there are other pure elements we should pre-calculate and have available to save time...
I have updated the BulkPureElements ZIP file with many more pure element calculations (now 75 MB) for use in extracting k-ratios from Penepma calculations as described here:
http://probesoftware.com/smf/index.php?topic=202.msg1506#msg1506
Download the update ZIP file here:
http://probesoftware.com/download/BulkPureElements.ZIP
-
I've updated the Bulk Pure Element ZIP file for Penepma. There are now 98 MB of pure elements calculated (at 40 degrees takeoff) and for 10, 15 and 20 keV.
These files can be utilized to automatically load intensities for "standards" for k-ratio extractions in Standard.exe. Download from here:
http://probesoftware.com/download/BulkPureElements.ZIP
Edit by John: Updated again Oct 28 2014 and now containing 102 MB of compressed Penepma pure element simulations for quant.
-
I've been recalculating a large number of light element binaries (to include MC modeling down to the lowest energy edge emitter) and pure elements (at twice the precision as previously, i.e., 7200 sec per beam energy versus 3600 sec per beam energy) and the results look very encouraging.
As an example of "spurious accuracy" (that is, too good to be true, but happens to be the case) I tested the N-Cr binary (seriously, it was the first one I tested!), and the results calculated using the 1% N 99% Cr in Standard.exe are seen here:
(https://probesoftware.com/smf/oldpics/i57.tinypic.com/2v0l7op.jpg)
Looks pretty good for such as large matrix correction (compare the k-ratio% to the wt%), but zooming in further reveals the "spurious accuracy" mentioned previously:
(https://probesoftware.com/smf/oldpics/i58.tinypic.com/2nhotbq.jpg)
Edit by John: Note that Xavier Llovet and Cesc Salvat are fixing a bug in Penepma/Penfluor for calculation of B Ka intensities, so stay away from boron as an emitter until the new version is released.
-
Again, remember that you should avoid modeling B Ka until the Penepma bug is fixed by Salvat and Llovet, but in the meantime you can easily model other low energy lines such as Cu La by following the instructions here:
http://probesoftware.com/smf/index.php?topic=47.msg2098#msg2098
-
Xavier Llovet reports the following on the B ka issue in Penepma/Penfluor:
Just to let you know that actually you didn't find a bug in the program. The problem comes from the database that PENELOPE uses for X-rays (EADL from Lawrence Livermore lab) that starts at Z=6, i.e. for Carbon!!
This database contains the radiative and non-radiative probabilities for all possible electron transitions so we're now trying to find these data for B, Be and Li.
I'll keep you posted.
-
Here's something to think about.
Here are two plots of the k-ratio (%) for Cr ka in N for both 99% Cr and 1% Cr. Interesting in the 99% plot how much difference there is between the Penfluor/Fanal Monte-Carlo output and the CalcZAF analytical expressions. See the graph attachments (you need to log in to see attachments!).
I don't think the large difference at low overvoltages is due to precision issues as the curve is very smooth. By the way, the standard (pure Cr) was calculated at 14400 sec per beam energy. Yes, 40 hours!
-
I've calculated pure elements from V to Cu down to 500 eV (40 hours each simulation time) in the latest penepma12.zip file:
http://probesoftware.com/download/PENEPMA12.ZIP
These PAR files will be useful as standards for those that want to model L lines for these transition elements.
john
-
In case anyone is interested, I've attached a pdf of the Penepma/Penfluor tutorial presentation I gave at the EPMA 2016 topical conference this week in Madison (remember, you have to be logged in to see attachments).
The CalcZAF and Standard apps can be downloaded here:
http://www.probesoftware.com/download/CalcZAF.msi
-
In v. 11.7.2 of CalcZAF (and Standard) I added three new parameter fields to the Penepma GUI. These are for the minimum and maximum energy range and the number of energy channels. This required a re-compile of the Penepma.f to allow for more than 1000 energy channels.
(https://probesoftware.com/smf/gallery/1_03_12_16_6_07_14.png)
The reason for doing this is also to allow me to synthesize WDS spectra for "demo" as described here:
http://probesoftware.com/smf/index.php?topic=837.0
where we will require some 10,000 to 20,000 energy channels for simulating WDS spectral resolution...
john
PS if you specify more than 1000 energy channels in the Penpma GUI, the software will remind you that you will need to utilize the CalcZAF Help | Update CalcZAF menu as seen here:
(https://probesoftware.com/smf/gallery/1_03_12_16_6_14_44.png)
to update your Penepma distribution.
-
Cesc Salvat gave me the Java app that his son developed for creating Penepma geometry (*.geo) files for Penepma calculations. See attached ZIP file below (remember to login to see attachments).
I tried to run it on my laptop but didn't have Java installed. Apparently if you have the Firefox web browser you will already have Java installed. Nicholas Ritchie says if you do download the Java installer from Oracle, you need to:
Either double click on the jar file or "javaw -jar salvats.jar" from the cmd window having "cd”d to the jar path. You will have to complete some paths to get this to work.
Again I haven't tried this yet but wanted to get it out there ASAP for people who want to create specialized geometries that aren't included in the CalcZAF/Standard distribution.
Of course please feel free to post any .geo files you have created if you think they might be useful to the general community.
john
-
After I saw Xavier's poster on optimizing the "interaction forcing factors" in the Penepma input, I had him help me modify the default forcing factors in the input files in the Penepma12.zip distribution. Use the Update Penepma12.zip option in the CalcZAF (or PFE) Help menu to get these new forcing factor input files.
As an example here are the forcing factors in the original input file for characteristic x-ray production:
>>>>>>>> Interaction forcing.
IFORCE 1 1 4 -10 0.1 1.0 [KB,KPAR,ICOL,FORCER,WLOW,WHIG]
IFORCE 1 1 5 -400 0.1 1.0 [KB,KPAR,ICOL,FORCER,WLOW,WHIG]
And here are the new forcing factors that Xavier implemented:
>>>>>>>> Interaction forcing.
IFORCE 1 1 4 -10 0.9 1.0 [KB,KPAR,ICOL,FORCER,WLOW,WHIG]
IFORCE 1 1 5 -100 0.9 1.0 [KB,KPAR,ICOL,FORCER,WLOW,WHIG]
One should be able to get better precision in less time with these new parameters.
-
Does anyone have a feel as to whether the number of elements slows down simulations. If I include trace elements do I reduce the precision on the majors for a given time.
Ben
-
Please, I am on the PENEPMA code and I would like to calculate the efficiency of the detector.
Is there information about the efficiency in the output file and how to extract them?
-
Please, I am on the PENEPMA code and I would like to calculate the efficiency of the detector.
Is there information about the efficiency in the output file and how to extract them?
Hi Nabil,
I am not sure I understand the question.
Are you refering to the efficiency of a real detector or the efficiency of the simulated detector? Or are you asking about the geometric efficiency of the simulated detector (subtended angle)?
I asked Xavier Llovet about your question and he responded with this which he asked me to post for him:
PENEPMA detectors are assumed to have an intrinsic efficiency of 100% (i.e. all photons crossing the detector surface are counted) and there's no need to worry about the geometric efficiency because X-ray intensities are given in units of photons/sr/electron, so the detector size is already accounted for.
Does this answer your question?
-
Thank you Probeman.
No my question is for the intrinsic detection efficiency, ie the number of events detected per those emitted.
-
Thank you Probeman.
No my question is for the intrinsic detection efficiency, ie the number of events detected per those emitted.
Ah.
So the answer to that is simply the geometric efficiency of the specified detector geometry. The default in the Standard GUI for Penepma is an annular detector (360 degrees). This is specified in this line of the .in (input) file:
PDANGL 45.0 55.0 0.0 360.0 0 [Angular window, in deg, IPSF]
-
Good evening.
My work on this code is to calculate the intrinsic efficiency of a detector, the problem is that this detector needs at least four materials but the standard.exe interface gives the possibility to use two materials only.
Can you help me ?
-
Good evening.
My work on this code is to calculate the intrinsic efficiency of a detector, the problem is that this detector needs at least four materials but the standard.exe interface gives the possibility to use two materials only.
Can you help me ?
Maybe. But can you explain what you mean by "intrinsic efficiency"? Every photon that hits the specified Penepma detector geometry is counted, so to me that means that the "intrinsic efficiency" of the Penepma detector is 100%. Of course since the Penepma detector is not a sphere (though one could define it as such!), some emitted photons will miss the detector. Again, as Xavier previously stated the output intensities are normalized to area so this really should not matter.
As for more than utilizing more than two materials, Standard is designed for the most common situations of a bulk material, a couple (boundary) with two materials or a thin film on a substrate. If you want to utilize more than two materials you will have to edit the Penepma .in file using a text editor. Here is an example for using three materials in Penepma:
http://probesoftware.com/smf/index.php?topic=57.msg478#msg478
You will need to add a 4th material in your case, again using any text editor on the .in file.
-
Probeman,
I appreciate the source code for the penepma-16 release. I noticed that this version is limited to 1000 energy bins. The penepma-12 version happily computes 4096. I'm guessing you modified the code. I noticed many of the variables were limited to 1000 channels. I'd be interested in knowing what changes you made... I have the -16 release running on my Win 7 box and my macbook. Given the large code base of simulations with the -12 release, I'd like to get that to run on my mac. It is the fastest box I have... I have learned a lot getting into the code over the last few days...
Best regards,
John
-
Hi John,
I have not touched the 2016 FORTRAN code I sent you- it came directly from Xavier.
The default number of bins in Penepma was 1000. I changed the 2012 code to 4096. It was originally intended for EDS simulations in my Standard app. In fact in the simulation mode in Probe for EPMA the default is 1 EV per channel just so I can synthesize WDS scans!
I'm pretty sure I added comments where ever I made a change in the 2012 FORTRAN. Most of my changes were in the Fanal code to get output of more parameters for the calculations of secondary fluorescence from boundaries.
-
I should also mention that Xavier asked me not to distribute any modified FORTRAN code. That is why the Penepma FORTRAN files are not found in the CalcZAF Github site.
But below I've attached my batch files for compiling the FORTRAN using GNU.
-
Thanks. I did a search and replace and changed the limits in penepma16 to permit 4096 channel spectra. It compiled as expected and I just started a run. I took a peek at the first pe-spect-01.dat file and I am indeed getting 4096 channels. Woo. Hoo! It is late here in Rochester, so I will let this run tonight and see what I get in the morning.
The advantage of the penepma2012 code is that all the users of CalcZaf can use it. Maybe I should standardize on that and consider building the 2012 code on the mac. If you zip and send the unmodified source I will make the changes for 4096 channels and build it on the mac. I would offer to send the binaries back to you, but given Xavier's wishes, I understand why I should not send them back...
Best regards,
John
-
Thanks. I did a search and replace and changed the limits in penepma16 to permit 4096 channel spectra. It compiled as expected and I just started a run. I took a peek at the first pe-spect-01.dat file and I am indeed getting 4096 channels. Woo. Hoo! It is late here in Rochester, so I will let this run tonight and see what I get in the morning.
The advantage of the penepma2012 code is that all the users of CalcZaf can use it. Maybe I should standardize on that and consider building the 2012 code on the mac. If you zip and send the unmodified source I will make the changes for 4096 channels and build it on the mac. I would offer to send the binaries back to you, but given Xavier's wishes, I understand why I should not send them back...
Best regards,
John
Hi John,
I don't think Xavier cares if I send you the modified FORTRAN codes, just that I don't generally distribute them publicly. I will send them as ZIP files to your email, and hopefully they won't get rejected by your mail server.
john
-
But after adding the 4th material, how can you read this .in input file?
And as far as efficiency is concerned, I'm talking about the efficiency of non-geometric detection, ie the photon detection capability.
With all my respectful greetings.
-
But after adding the 4th material, how can you read this .in input file?
Using Penepma from the Standard GUI or from the command prompt, e.g., Penepma.exe < inputfile.in
I think you should sit down with the Penepma documentation and read through it carefully. See the file penepma.pdf and work through the section titled "An example".
And as far as efficiency is concerned, I'm talking about the efficiency of non-geometric detection, ie the photon detection capability.
With all my respectful greetings.
As Xavier and I already said, 100% of the photons that intersect the Penepma detector geometry are counted and normalized to area.
john
-
Thank you very much my brother Probeman.
-
Thank you very much my brother Probeman.
You are most welcome.
john
-
Thanks. I did a search and replace and changed the limits in penepma16 to permit 4096 channel spectra. It compiled as expected and I just started a run. I took a peek at the first pe-spect-01.dat file and I am indeed getting 4096 channels. Woo. Hoo! It is late here in Rochester, so I will let this run tonight and see what I get in the morning.
The advantage of the penepma2012 code is that all the users of CalcZaf can use it. Maybe I should standardize on that and consider building the 2012 code on the mac. If you zip and send the unmodified source I will make the changes for 4096 channels and build it on the mac. I would offer to send the binaries back to you, but given Xavier's wishes, I understand why I should not send them back...
Hi John,
I have to admit that I haven't had a chance to play with the Penepma 2016 code yet, but I would be very interested to learn if the input/output file formats have changed enough to break our Penepma 2012 GUI code in our Standard app. That would be the .in input file and the Penepma output files here:
PENEPMA_DAT_File$ = PENEPMA_Path$ & "\PENEPMA.DAT"
PENEPMA_SPEC_File$ = PENEPMA_Path$ & "\PE-SPECT-01.DAT"
PENEPMA_CHAR_File$ = PENEPMA_Path$ & "\PE-CHARACT-01.DAT"
If you get a chance and compile the Penepma 2016 FORTRAN for a PC, please feel free to drop a copy of the Penepma.exe into the C:\UserData\Penepma12\Penepma folder and see if our Standard GUI still works. I suspect it won't but it's worth a try.
john
-
This was actually fun and was yet another learning opportunity. The only modification I made to Prof. Llovet's 2016 code was to increase the limit on the number of channels from 1024 to 4096. The orthoclase.in example from the 2012 version ran (using material files I created from the 2016 version of material.exe), but stopped after the first dump of the simulation. This may be a "feature" but was unexpected based on the information in the input file. I am attaching a modified input file that works as expected and is chugging along at the moment.
There are some incompatibilities between the two versions, so I would not mix the two versions in the same folder in C:\UserData\Penepma\Penepma. Note that in the standard installation, the material.exe file for the 2012 version is in the Pendbase folder. I did not want to disturb this standard set-up so I created a pair of folders in my user space.
C:\Users\username\Documents\work\penepma12
and
C:\Users\username\Documents\work\penepma16
Each of these folder has a pendbase folder that contains the appropriate material.exe and pdfiles folder for that version of the software. This keeps material files separate. The user needs to create the materials file for the 2016 version from the command line.
For a given simulation I create a subfolder with a meaningful name in the folder for the version to be used. This is where we store the .in file for the simulation, the material files to support the simulation, and the appropriate geometry file. I also include a batch file that looks like this:
cd "C:\Users\username\Documents\work\penepma16"
REM Start clean...
del /f *.dat
del /f *.rep
penepma16 < "orthoclase.in"
pause
I then have penepma executables named penepma12.exe and penepma16.exe that I put in a folder in system path. The batch file calls the appropriate exe for the simulation...
I'd be willing to zip up the files you need and get them to you. Hope this helps...
Update 6:52 pm EST: The simulation finished. I am attaching a png of the spectrum on a log scale and the pe-spect-01.dat and pe-intens-01.dat files from a 5 hr simulation.
Best regards,
John
-
Purely from recollection, for an epma with a take off angle of 40degrees, the .in takeoff angle may need to be amended (measured from the vertical)
And, personally speaking, I think, rather than running for a set time, its better to use the REFLIN option to specify an error on a line if interest.
Other things of note - c1 and c2 should be checked to see if they influence the results. Experience says maybe not, but depending on what your trying to achieve, they should be checked with short runs. Efficiency is definitely optimised by choosing the input parameters - especially the cutoffs - in this line carefully.
Actually, is anyone interested in an 'end users' guide to penepma? Once I fully understand some of the more esoteric details of the new version, I don't mind putting something together detailing this, .geo and a basic guide to Penelope for xrf and the like (this will mean I have to bribe Xavier with a beer for three!). But only if there's interest.....
The PENELOPE family, together with the Salvat database on cross sections are excellent resources for things as diverse as BSE and X-ray yield across a range of analytical techniques. The authors really cannot be given enough credit for a serious contribution and should be both applauded and supported.
-
Actually, is anyone interested in an 'end users' guide to penepma? Once I fully understand some of the more esoteric details of the new version, I don't mind putting something together detailing this, .geo and a basic guide to Penelope for xrf and the like (this will mean I have to bribe Xavier with a beer for three!). But only if there's interest.....
The PENELOPE family, together with the Salvat database on cross sections are excellent resources for things as diverse as BSE and X-ray yield across a range of analytical techniques. The authors really cannot be given enough credit for a serious contribution and should be both applauded and supported.
Hi Jon,
I could not agree more with you. What Cesc and Xavier have done is very impressive. They deserve enormous credit for what they have accomplished.
On the basic guide thing, one user here did start a short tutorial here (see attached pdf):
http://probesoftware.com/smf/index.php?topic=322.msg1641#msg1641
But there would be value in different approaches as you suggest and I would strongly encourage you to proceed. I think the learning curve for Penepma is pretty steep (which is why I created a basic GUI for it in CalcZAF/Standard), so any sort of instructional manual would be very helpful.
Maybe some "case studies"?
john
-
I am very interested in your "end user guide." I have currently been exploring the effects of changing the MSIMPA parameters for trilayer simulations where I have something like a thin C coating on ZnO on silica. I'm also interested in a case where one might replace the ZnO with a more dense material like Ag where one has something light like silica underneath.
I am aware of Sherri Singerling's document. I have been working on a R package to process the output. My goal is to run the analysis in code chunks in a Rmarkdown document for a reproducible report that could be shared with others and easily modified to extend the analysis.
-
Jon Wade,
I am trying to figure out the code for the REFLIN syntax and make sure
I understand the rationale for the choices. A while ago you sent me this
example for a simulation with Ir:
REFLIN 77081500 2 1.E-2 [IZ*1e6+S1*1e4+S2*1e2,detector,tol.]
The handy code suggests it will compute IZ*1e6+S1*1e4+S2*1e2,detector,tol..
I needed the code for the shells and found table 7.2 in the
Penelope-2014 NEA document by Salvat (attached for those who are interested.)
So S1 would be 08 (M4) and S2 would be 15 (N6).
I checked the transitions with DTSA-II listTransitions('Ir') function, I get
the table below that I cropped to the transitions with a large weight.
IUPAC Weight Energy Wavelength
(keV) (Å)
Ir M5-N6 1.0000 1.977 6.27133
Ir M5-N7 1.0000 1.9799 6.26214
Ir M4-N6 0.5944 2.0527 6.04005
Ir L3-M5 1.0000 9.1748 1.35136
Ir L2-M4 0.4168 10.708 1.15787
I am assuming you choose the lower weighted M4-N6 because if
those statistics were good, the higher weighted L3-M5 would be better.
Did I miss anything? Do you have any other helpful hints for how to
optimize a simulation using REFLIN?
Thanks for all your help. This is a great community.
Best Regards,
John Minter
-
Hi John
Can't remember why I picked M4-N6 - its possible I didn't really care too much about which line I chose (typically, I'm not interested in Ir - we use its Fe content as a redox sensor - hence I'm usually more interested in the Fe it contains).
The REFLIN function is really nice to use if you want the same precision across a number of runs, or if you batch-up runs and want to run the next as soon as you hit a reasonable precision on an element of interest.
When the kids go back to school I'll start on an end-users guide. I'm not sure about the change in 'channels' when binning - the newer version merely reports intensity on lines, with the background subtracted (Pe-intens_xx.dat), and a list from the detector in pe-spect-xx.dat. I am unsure if the number of channels significantly effects the former. I'll buy Xavier a beer and find out......
-
We fixed a small bug in the Penepma GUI that was not setting the WCC and WCR parameters to the same minimum energy values as the electron and photon limits. Thank-you to Philippe Pinard who pointed this out.
We also are now setting the *position* minimum energy parameter to the same value as the electron and photon minimum energy parameters, just for those of you working with anti-matter samples! :D
-
The 2008 paper by Llovet and Salvat show an example in Figure 5 on p. 24 of a "Measured spectrum from detector number 1 (see the penepma input file epma2.in) calculated by convolving the simulated spectrum with the energy resolution function of a Si(Li) detector."
I have been unable to figure out how they actually created that spectrum. I checked the CalcZAF code on github and noticed that there are references in penepma8a.bas to "PENEPMA_CONVOLG_File" but I can't see how to create this in the input file or that it is actually used. Many of you have wrestled with this code more than I have. Any chance you can explain what I am missing?
Llovett and Salvat have done great work putting this program together. It would be much easier for people to use it if the .in files for key examples were in a github repository someplace - arranged by release because the best practices have changed over time. I am assembling some examples of my own. I'd be willing to help maintain such a github repository. I have both time and interest. I suspect Jon Wade could and would contribute as well. Do you think Llovet and Salvat would be interested is supplying some of their examples?
Best Regards,
John Minter
-
Guess I should start with a Homer Simpson Doh! I just needed to look in the right place. I noticed that CalcZAF has the programs convolg.exe, convolg_LDE.exe convolg_LIF.exe convolg_PET.exe and convolg_TAP.exe alongside penepma.exe. The first lets you input a spectrum name and an eV for convolution. Assuming that the others are for the typical crystals. Guessing I could wrap these in batch files. For the moment I put convolg.exe in my path... Update: found the Fortran code and built these on the Mac as well...
-
Guess I should start with a Homer Simpson Doh! I just needed to look in the right place. I noticed that CalcZAF has the programs convolg.exe, convolg_LDE.exe convolg_LIF.exe convolg_PET.exe and convolg_TAP.exe alongside penepma.exe. The first lets you input a spectrum name and an eV for convolution. Assuming that the others are for the typical crystals. Guessing I could wrap these in batch files. For the moment I put convolg.exe in my path... Update: found the Fortran code and built these on the Mac as well...
Hi John,
This post has the convolution equation codes for the various WDS crystals that I modified the convolg FORTRAN with for the WDS convolg exes that you listed above:
https://probesoftware.com/smf/index.php?topic=837.msg6187#msg6187
I use the default convolg program for simulating EDS spectra and the modified codes for simulating WDS spectra, in Probe for EPMA for demonstration and teaching. It is quite realistic. That is correct: you don't need an actual microprobe to perform micro-analysis in PFE! :)
john
-
This has been an interesting project over the weekend. I have been working with penepma16 using the REFLIN parameter to stop a simulation when it reaches a desired tolerance (relative uncertainty). The key problem I encountered is finding suitable tolerance value that will be reached in a reasonable simulation time.
I simulated a simple example of a 100 nm Al film on Fe at 20 kV using the Fe K-L3 line for the REFLIN parameter. This is a long simulation because of the deep penetration of the electron beam into the Fe substrate at 20 kV. My objective was to be able to predict the simulation time based on the tolerance criterion.
I set up the simulation with a dump time of 120 sec. I wrote a function in R to read the penepma-res.dat file that is produced and extract the simulation time, the number of showers (trajectories) and the current value for the tolerance (relative uncertainty). I (manually) recorded the tolerance value after each dump time and stored the data file for later modeling. It ran for 2.7 hrs to get just over 25000 trajectories.
It turns out that one can predict the time to reach a given relative uncertainty (tolerance) by fitting the data to a model where the simulation time in sec is fit to (1/tolerance)^2 (see the attached plot). The coefficient for this transition was 384.5 with a standard error of 1.068. Running the simulation to a tolerance of 0.2 required 2.7 hrs. Running the simulation to a tolerance of 0.05 would require 42.7 hrs!
I suspect that the time to reach a given tolerance would be lower for measurements at lower accelerating voltages because each trajectory would be shorter.
This is a work-in-progress. The function call will fail if penepma is writing the penepma-res.dat file at the time the query is made. I am still figuring out how to automatically run the query in a loop and write the results to a file for later analysis.
-
I'm curious if anyone knows whether or not this problem could also be solved via a GPU platform. My understanding is that they're great when you have the same starting data but not necessarily efficient if you have to keep loading in new operations, and I don't know enough about how these things are calculated to even make a guess as to whether or not it would be useful to look in to.
Any thoughts? I've done a bit of spot reading, and it looks like if enough data can be loaded into the initial set (eg you're not constantly sending and retrieving the data through the PCIe bus) and the process is parallelizable it *might* work. Of course, might also be cheaper to just rent some Amazon EC2 time and do several days of computing in an hour.
-
Neko, I suspect a port to use a GPU would be a major undertaking. The base penelope/penepma code only uses a single core. There is a provision for using different random number seeds, running multiple simulations on different cores and combining the results. There is also a multi-core version developed by Oak Ridge National Laboratories. I understand that there are differences in input because of this. I have not heard any one on this forum claim to use it.
My main purpose in running the experiment to understand how the required simulation time varied with the desired precision was to get an idea how to manage an uncertainty budget in an analysis and to be able to predict how long a simulation with a desired uncertainty would take based on a trial simulation.
More of my effort has been dedicated to designing a R package to automate analysis of the output and make it easier to write a reproducible report. I found myself repeatedly writing similar code, which is a key sign that one needs to package functions under version control and use unit tests.
Hope this helps,
John
-
Philippe Pinard, Hendrix Demers and I recently noticed that the x-ray intensities calculated from using a few of the pure element PAR files in the Standard GUI for Penefluor/Fanal were not correct. This was only the case for the gaseous elements: N, O, F, Ne, Cl, Ar, Kr, Xe and Rn. Now I don't suppose that many of you actually utilize pure gases as standards, even for your simulations, but we discovered the issue while writing up a paper on the use of alpha factors from Monte Carlo generated intensities
This was because I had assumed the room temperature densities for calculating the material files for these gaseous elements (if we had evolved on Pluto this would not have been an issue!). :D
The gaseous densities (~10^-3) were problematic because the default "bulk" geometry file (bulk.geo), specifies a thickness of only 0.1 cm or 1 mm. This makes these gaseous pure elements essentially a thin film experiment where some of the incident electrons actually transmit through the specimen geometry resulting in too low a generated x-ray intensity! Our solution was to simply force the pure gaseous element densities to 1.0 if they were less than 1.0. Obviously you can modify the densities from the GUI to whatever values you want and re-calculate them, and/or edit the bulk.geo file geometry, if you prefer.
So we re-calculated these gaseous pure elements (N, O, F, Ne, Cl, Ar, Kr, Xe and Rn) and they are now available for download by using the Help | Update menu in either CalcZAF or Probe for EPMA, by checking the Update Penepma Monte Carlo Files as seen here:
(https://probesoftware.com/smf/gallery/1_03_12_16_6_14_44.png)
Remember, if you haven't updated CalcZAF and/or Probe for EPMA since we switched to secure https connections in August this year, you will need to manually download the CalcZAF.msi and/or ProbeForEPMA.msi installers on this page:
https://probesoftware.com/Update.html
and run the installer manually once. After this, you can continue to update CalcZAF and/or Probe for EPMA from the Help | Update menu again.
Or you can manually download the Penepma12.zip file from the various download sites if you prefer and unzip it to your user data folder (usually C:\UserData\Penepma12). The actual pure element PAR files are in the \Penfluor\Pure sub folder.
-
Attached is a plot of some BSE simulations I did recently for pure elements in Penepma (Penelope) 2012 (please login to see attachments).
My question is: are these BSE fluctuations for these pure elements, e.g., around Z = 35 or so, we are seeing in the Penepma calculations, confirmed by empirical measurements? What I mean, is there a physical basis for these BSE fluctuations in the Penepma modeling? Or is it an artifact of the elastic scatter modeling in Penepma?
I asked Xavier Llovet and he said: good question!
As he also pointed out, it would be difficult to get enough sensitivity to see this empirically, but I might give it a try. Does anyone have any thoughts on whether this is just a modeling artifact? Has any one tried to see this with other MC software?
-
I posted an image in the previous post as an attachment a few days before Christmas so not sure how many people saw it. Here it is again as an in-line image:
(https://probesoftware.com/smf/gallery/395_07_01_19_4_45_28.png)
At that time I asked if anyone had noticed whether any other MC software packages show the same discontinuous trends (e.g., around Z=35), for the pure elements.
I haven't had a chance to try other MC programs, but I wondered (because this data was calculated from several different computers), if these discontinuities were just an artifact of statistics, so I ran a longer calculation on a single computer over the holidays and obtain this for pure elements between Z = 30 to 40:
(https://probesoftware.com/smf/gallery/395_07_01_19_4_46_48.jpeg)
The variances are shown as the tiny errors bars. So at least Penepma is consistent. But why these discontinuities occur, for example between Se (34) and Br (35), I have no idea.
john
-
So in addition to the small increase in BSE from atomic number 34 to 35 (Se to Br):
34 0.3389
35 0.3393
There is also a small change (actually a decrease!) from 58 to 59 (Ce to Pr):
58 0.4277
59 0.4276
Does this make any sense to anyone?
-
Yeah, it does make sense in my head at least - this is what I was thinking about back in August on the brain teaser thread (assuming I'm right, of course - something which should never be assumed!). Link to the brain teaser thread:https://probesoftware.com/smf/index.php?topic=1111.msg7468#msg7468 (https://probesoftware.com/smf/index.php?topic=1111.msg7468#msg7468).
To paraphrase Goldstein et al*, the elastic scattering events that combine to form the BSE emission result from an interaction of the primary electron beam with the electrical field of an atom i.e. the positive nuclear charge of an atom as shielded by the electron cloud.
It is this effect of the electron shielding that I think you are seeing here.
I've pulled some numbers off the web for the effective nuclear charge at the valence shell (which shell is valence? discussed briefly below) and plotted these up in the attached images - I hope you agree the plot for the effective nuclear charge, Zeff, as a function of atomic number for the elements Z= 30 to 40 looks similar to the plot of BSE coefficient vs Z. What I haven't figured out is why it appears to be offset by 1 compared to your data?
The plot of the 6s subshell for Z = 55 to 61 also show the decrease you were referring to (and in the right place this time!). I've plotted up the 6s and 4f subshells for Caesium (Cs) to Promethium (Pm) (no 4f for Cs and Ba - the 4f energy level is higher than the 6s and so 6s fills first). Why does the 6s subshell show the BSE pattern whereas the 4f doesn't if the 4f is higher energy and so shouldn't it be further from the nucleus and therefore the valence orbital? Not quite... Despite the 4f being higher energy than the 6s, the 4f electrons have a higher probability of being closer to the nucleus than the 6s owing to the shape of the orbitals. The Encyclopedia Britannica actually has a nice diagram of the probability of electron position for Gadolinium (Z= 64) with electron configuration [Xe].4f7.5d1.6s2:
(https://www.britannica.com/science/rare-earth-element/media/491579/187149)
(link for if the image doesn't work: https://www.britannica.com/science/rare-earth-element/media/491579/187149 (https://www.britannica.com/science/rare-earth-element/media/491579/187149))
Further to this, the filling of the subshells in the lanthanide series also unusual: the electron configurations of Cs and Ba are as expected [Xe].6s1 and [Xe].6s2; but La skips the 4f subshell and starts filling up the higher energy 5d subshell [Xe].5d1.6s2; Ce starts filling up the 4f subshell [Xe].4f1.5d1.6s2; and then Pr dumps the 5d subshell and moves the electron in to the 4f to get [Xe].4f3.6s2 (no 5d electrons).
I think all the wobbles and fluctuations you see through the BSE vs Z model that has been posted are mostly caused by these electron subshell filling/nuclear screening artefacts. If so, I'm actually quite impressed that the MC simulations show it.
*Scanning Electron Microscopy and X-Ray Microanalysis, 4th Ed., Chapter 1, page 4
-
Hi Jon,
Wow, this is super interesting!
First of all the BSE brain teaser that Ben and you and I were discussing is a slightly different issue (in my mind anyway), as that is more related I think to how one should calculate average Z for compounds. Hence the Z fraction to the 0.7 exponent model. The value of 0.7 for the exponent is necessary to calculate the effect of nuclear screening by inner orbitals in higher atomic number elements (it's why the BSE coefficient tends to increase less as Z increases). That and the fact that the number of neutrons tends to increase faster than the number of electrons and protons as the atomic number increases is why using mass fraction skews the average zbar calculation at higher atomic numbers. See a plot of A/Z for the periodic table and it will make sense.
If it wasn't for this nuclear screening, we could just use a simple z fraction for compounds. By the way, if you'd like to compare a number of average Z calculations, simply check the Calculate Alternative Zbars in the Output menu of the Standard application.
Now as for these wriggles in the plot of the pure elements I think you nailed it. I would never have guessed that the outer electron shells would have that much effect on elastic scattering. Though I agree that it's odd about the change in BSE coefficient from 34 to 35, versus the change from 35 to 36 in the effective charge. But I double checked the Penepma calculations and I did seemingly type them into the spreadsheet correctly from the penempa.dat files. Here is a section:
Atomic Number BSE Coefficient BSE variance Zbar (mass) Zbar (zfrac) Zbar (zfrac^0.7)
29 0.3130 0.00015 29 29 29
30 0.3175 0.00015 30 30 30
31 0.3233 0.00015 31 31 31
32 0.3308 0.00016 32 32 32
33 0.3346 0.00016 33 33 33
34 0.3389 0.00016 34 34 34
35 0.3393 0.00008 35 35 35
36 0.3445 0.00008 36 36 36
37 0.3492 0.00009 37 37 37
38 0.3527 0.00009 38 38 38
Attached below is the complete Excel spreadsheet with the Penepma pure element values.
john
-
Hi John,
First of all the BSE brain teaser that Ben and you and I were discussing is a slightly different issue (in my mind anyway), as that is more related I think to how one should calculate average Z for compounds.
Yeah, I realised at the time that I'd wandered off on a tangent. The thing that got me started there wasn't the average atomic number, but rather why were we using the atomic number at all - integer values always seem a bit too convenient! That said, trying to determine the average Z[eff] to account for bonded atoms in an unknown material might be challenging!
The value of 0.7 for the exponent is necessary to calculate the effect of nuclear screening by inner orbitals in higher atomic number elements (it's why the BSE coefficient tends to increase less as Z increases).
I assume this is in addition to the decreasing proportional effect of adding one more proton to the nucleus e.g. adding 1 proton to H will double the proton number, add 1 proton to La makes less of a proportional difference (1/57)?
Now as for these wriggles in the plot of the pure elements I think you nailed it. I would never have guessed that the outer electron shells would have that much effect on elastic scattering. Though I agree that it's odd about the change in BSE coefficient from 34 to 35, versus the change from 35 to 36 in the effective charge. But I double checked the Penepma calculations and I did seemingly type them into the spreadsheet correctly from the penempa.dat files. Here is a section:
Atomic Number BSE Coefficient BSE variance Zbar (mass) Zbar (zfrac) Zbar (zfrac^0.7)
29 0.3130 0.00015 29 29 29
30 0.3175 0.00015 30 30 30
31 0.3233 0.00015 31 31 31
32 0.3308 0.00016 32 32 32
33 0.3346 0.00016 33 33 33
34 0.3389 0.00016 34 34 34
35 0.3393 0.00008 35 35 35
36 0.3445 0.00008 36 36 36
37 0.3492 0.00009 37 37 37
38 0.3527 0.00009 38 38 38
That is strange - I'm wondering whether we're looking at a spatial effect as well as a screening effect ie the probability of where the primary beam electron would interact with the atom and whether this occurs between shells or is considered only outside of the atom (and hence would experience the complete shielding effect as seen by the valence shell).
Or whether the numbers either penepma - or more likely I - used are wrong - there was a bit of variation in the numbers I found..
Either way, there's obviously something else going on here that I haven't figured out yet...
-
This question came up off-line so I thought I would mention it here.
When running Penepma from the GUI in the Standard application, the random seed is *not* varied. This is for reproducibility of results.
However when running Penepma from Probe for EPMA to simulate EDS spectra, the random seed *is* varied.
To add a random seed in the Penepma input file simply add a line like this to your .in file:
RSEED 1 2 [Seeds of the random-number generator]
The defaults are 1 and 2 so you should change them if you want to simulate random statistics, though the Penepma documentation does not explain exactly how they are utilized that I can find. Except for this bit of code:
C *********************************************************************
C FUNCTION RAND
C *********************************************************************
FUNCTION RAND(DUMMY)
C
C This is an adapted version of subroutine RANECU written by F. James C (Comput. Phys. Commun. 60 (1990) 329-344), which has been modified to
C give a single random number at each call.
C
C The 'seeds' ISEED1 and ISEED2 must be initialised in the main program
C and transferred through the named common block /RSEED/.
C
IMPLICIT DOUBLE PRECISION (A-H,O-Z), INTEGER*4 (I-N)
PARAMETER (USCALE=1.0D0/2.147483563D9)
COMMON/RSEED/ISEED1,ISEED2
C
I1=ISEED1/53668
ISEED1=40014*(ISEED1-I1*53668)-I1*12211
IF(ISEED1.LT.0) ISEED1=ISEED1+2147483563
C
I2=ISEED2/52774
ISEED2=40692*(ISEED2-I2*52774)-I2*3791
IF(ISEED2.LT.0) ISEED2=ISEED2+2147483399
C
IZ=ISEED1-ISEED2
IF(IZ.LT.1) IZ=IZ+2147483562
RAND=IZ*USCALE
C
RETURN
END
and the following text:
1.2.1 Random-number generator
In general, random-sampling algorithms are based on the use of random numbers » uniformly distributed in the interval (0,1). These random numbers can be easily generated on the computer (see, e.g., Kalos and Whitlock, 1986; James, 1990). Among the \good" random-number generators currently available, the simplest ones are the so-called multiplicative congruential generators (Press and Teukolsky, 1992). A popular example of this kind of generator is the following,
Rn = 75Rn¡1 (mod 231 ¡ 1); »n = Rn=(231 ¡ 1); (1.30)
which produces a sequence of random numbers »n uniformly distributed in (0,1) from a given \seed" R0 (< 231 ¡ 1). Actually, the generated sequence is not truly random, because it is obtained from a deterministic algorithm (the term \pseudo-random" would be more appropriate), but it is very unlikely that the subtle correlations between the values in the sequence have an appreciable e®ect on the simulation results. The generator (1.30) is known to have good random properties (Press and Teukolsky, 1992).
However, the sequence is periodic, with a period of the order of 109. With present-day computational facilities, this value is not large enough to prevent re-initiation in a single simulation run. An excellent critical review of random-number generators has been published by James (1990), where he recommends using algorithms that are more sophisticated than simple congruential ones. The generator implemented in the Fortran 77 function RAND (Table 1.1) is due to L'Ecuyer (1988); it produces 32-bit floating-point numbers uniformly distributed in the open interval between zero and one. Its period is of the order of 1018, which is virtually inexhaustible in practical simulations.
-
The small "steps" in the calculated BSE that I saw in Penepma 2012 appear to simply be statistical in nature. Varying the random seed for 4 different simulations I got this:
(https://probesoftware.com/smf/gallery/395_11_06_19_3_33_39.jpeg)
This is using these 4 seed statements:
RSEED 1 1 [Seeds of the random-number generator]
RSEED 2 2 [Seeds of the random-number generator]
RSEED 3 2 [Seeds of the random-number generator]
RSEED 4 2 [Seeds of the random-number generator]
I still find it odd that the variation doesn't appear totally random, but I'm guessing that these "steps" are not significant.
-
As many of you know, the boundary fluorescence calculations shown in this window, which are accessed from the Standard application:
(https://probesoftware.com/smf/gallery/1_16_01_20_1_43_39.png)
are based on the Penfluor/Fanal FORTRAN codes written by Cesc Salvat and Xavier Llovet. Penfluor (using Monte Carlo methods), calculates the primary and continuum x-ray productions from the primary electrons while Fanal (using analytical methods), calculates the fluorescence effects for boundary geometries (when the two phases are different) or for a bulk matrix (when the two phases are the same). This is described here and in the subsequent posts:
https://probesoftware.com/smf/index.php?topic=58.msg214#msg214
The thing is, even though the Penfluor code is based on Penepma, it parameterizes the results over 10 beam energies so there are some inaccuracies and more importantly it can only handle the simple mirror geometry of a vertical plane boundary. The mistake I made was that until recently I had named the title of the window "Calculate Penepma 2012 Fluorescence Couple Profiles", so some people thought the GUI was running the full Penepma code. But no it just utilizes the Penfluor/Fanal code. But it gets one lots of results in minutes (assuming you have the PAR files already calculated for the selected materials).
For ultimate accuracy one should utilize the full Penepma Monte Carlo code GUI, because it can handle any boundary geometry, though it does take a lot longer. However one can create a bunch of input files that can be run as a batch. This is this the GUI window running the full Penepma FORTRAN code, which is opened when clicking the Penepma Monte Carlo menu in Standard:
(https://probesoftware.com/smf/gallery/395_08_03_19_4_22_57.png)
Anyway, Xavier asked me to fix the title of the Penfluor/Fanal window as described above, so that is now done, and you can update to v. 12.8.2 any time using the Help menu in Probe for EPMA or CalcZAF.
-
John Donovan has graciously let me test a new Penepma dialog that uses penepma16 under
the hood. This is the current from release from Professors Llovet and Salvat. Everything worked
as expected for simulation of bulk standards.
When I tried the thin-film option from the new release, the penepma16 executable would crash
without an error message.
I had an old penepma16 simulation I had done in 2018 from a similar attempt that had worked
and was able to compare the two input files. The difference was:
I found the problem in the .in file
This works for a bilayer
.
>>>>>>>> Emerging particles. Energy and angular distributions.
NBE 0 4e3 1000 [E-interval and no. of energy bins]
NBANGL 45 30 [Nos. of bins for the angles THETA and PHI]
.
This is what the GUI for penepma16 generates
.
>>>>>>>> Emerging particles. Energy and angular distributions.
NBE 0 4e3 250 [E-interval and no. of energy bins]
NBTH 45 [No. of bins for the polar angle THETA]
NBPH 30 [No. of bins for the azimuthal angle PHI]
.
Note that the difference is the use of the NBANGL 45 30 that works
and the older sequence using two lines with NBTH and NBPH doesn't.
I don't think the different number of bins are important. This version
can easily handle 1000 bins...
Neither John Donovan nor I understand why the second doesn't work any longer.
-
Hi John,
I looked into this a bit more and I found that these parameters (NBANGL vs. NBTH, NBPH) are not actually created by the Standard GUI. The NBTH and NBPH parameters are respected and re-written if they are found, but I'm suspecting that they must have been in your original .in files for some reason.
Thanks for noticing this and I will add support for the NBANGL parameter as soon as I get a chance for Penepma16.
In the meantime I am calculating high precision spectra for Li, Be and B at a number of beam energies using Penepma16, but I'm not sure Penepma16 is any different for other elements. So sticking with Penepma12 for now is fine.
-
It appears that the NBTH and NBPH parameters are based on the Penepma 2012 "bilayer.in" file which is the default input file for thin film calculations. Apparently the boys in Barcelona must have changed this parameter in Penepma 2016.
So the best solution is to simply edit the bilayer.in file for the new parameter. I've attached a new version below that should work with Penepma 2016 and will upload a new Penepma16.zip file with this modification.
All I did was remove these two lines:
NBTH 45 [No. of bins for the polar angle THETA]
NBPH 30 [No. of bins for the azimuthal angle PHI]
And replace them with this line:
NBANGL 45 30 [Nos. of bins for the angles THETA and PHI]
That should work.
-
OK, we've uploaded a ZIP file containing executable and support files for Penepma 2016. You can access the link on this page:
https://probesoftware.com/Technical.html
or you can just grab it with this direct link:
https://probesoftware.com/download/PENEPMA16.ZIP
Here are the short instructions:
Penepma 2016 is almost identical with Penepma 2012, except that it provides support for emission lines of Li, Be and B. However, Penepma 2016 is not distributed with CalcZAF/Standard because the physics database files for Penepma 2016 are *not* compatible with the Penfluor/Fanal secondary fluorescence application files. Therefore Penepma 2016 is a separate download (here) which can be unzipped and placed in a folder named UserData\Penepma16, if desired for Li, Be and B emission calculations. To utilize the Penepma GUI in the Standard application one should edit the following enties in their Probewin.ini file:
PENDBASE_Path="C:\Userdata\Penepma16\Pendbase"
PENEPMA_Path="C:\Userdata\Penepma16\Penepma"
PENEPMA_Root="C:\Userdata\Penepma16"
PENEPMA_PAR_Path="C:\Userdata\Penepma12\Penfluor"
The above path to the Penfluor files isn't changed because the Penfluor and Fanal programs won't work with the Penepma 2016 physics database files.
We probably should re-do the code relating to the Penfluor path in CalcZAF, Standard and PFE, but right now if you want to run the Penfluor/Fanal GUI as described here:
https://probesoftware.com/smf/index.php?topic=58.0
for secondary fluorescence calculations at boundaries, you'll need to re-edit the Penepma paths in the Probewin.ini file back to Penepma12.
In the meantime this Penepma16.ZIP file contains sub folders of output files for pure Li, Be and B at 5, 10, 15, 20 and 25 keV. See the Penepma16\penepma\Batch folder.
-
Many thanks, John. You put a lot of work into this...
-
Many thanks, John. You put a lot of work into this...
Thank-you John.
I should also mention that in order to calculate intensities down to 50 eV (necessary for Li ka), the number of secondaries generated are too large for the "forcing factor" arrays as specified by default in the Penepma GUI.
For example, here are the default forcing factors generated by selecting the "Optimize Production of Characteristic X-rays" option (from the Cu_Cha.in file):
>>>>>>>> Interaction forcing.
IFORCE 1 1 4 -10 0.1 1.0 [KB,KPAR,ICOL,FORCER,WLOW,WHIG]
IFORCE 1 1 5 -400 0.1 1.0 [KB,KPAR,ICOL,FORCER,WLOW,WHIG]
It's the FORCER factor in red (-400) that causes the problem, so if you intend to calculate characteristic spectra down to 50 eV or so you should edit this number to -200 as seen here:
>>>>>>>> Interaction forcing.
IFORCE 1 1 4 -10 0.1 1.0 [KB,KPAR,ICOL,FORCER,WLOW,WHIG]
IFORCE 1 1 5 -200 0.1 1.0 [KB,KPAR,ICOL,FORCER,WLOW,WHIG]
Just FYI.
john
-
As many of you know, a distribution of Penepma 2012 is included for use with the Penepma GUI in the Standard program.
Recently we completed modeling the pure elements from Li to Cm at electron beam energies from 5 to 30 keV in 5 keV steps utilizing 1 eV bins for fine spectral details. These pure element spectra are used by Probe for EPMA to create synthetic WDS spectra as described here:
https://probesoftware.com/smf/index.php?topic=837.msg9198#msg9198
Also note that the spectra for Li, be and B were calculated utilizing Penepma 2016 which is not normally distributed, but see the previous two posts in this topic for instructions on downloading Penepma 2016 to your computer which can then be utilized with the Standard Penepma GUI.
Finally, once you are updated to the most recent Penepma distribution, the "pe-spect-01.dat" and "pe-intens-01.dat" files for each pure element are stored in these folders shown here:
(https://probesoftware.com/smf/gallery/1_24_11_20_1_38_08.png)
To download the most recent version of the Penepma 2012 distribution, simply use the "Update Penepma Monte-Carlo Files Only" check box from the CalcZAF or Probe for EPMA Help menus as shown in this post:
https://probesoftware.com/smf/index.php?topic=366.msg1936#msg1936
-
By the way, each of these pure element Penepma simulations at 5, 10 15, 20, 25 and 30 keV (using 1 eV energy intervals), were run for 144,000 seconds or 40 hours each!
If anyone is interested in the complete output files, just let us know and I can upload a zip of everything for downloading.
-
As you know, the Penepma/Penfluor/Fanal executables can be compiled as 32 bit or 64 bit programs. However we only distribute the 32 bit executables in the CalcZAF.msi distribution, because Microsoft still supports 32 bit operating systems (32 bit executables will run on either 32 or 64 bit operating systems, but 64 bit executables will only run under 64 bit operating systems).
One thing that we have come across (very rarely) is that once in a while, some of these 32 bit versions (e.g., Penfluor/Fanal) produce an error during execution. We have found that the same calculation using the 64 bit version does *not* produce any errors. However, as mentioned above, you must run the 64 bit Penepma/Penfluor/Fanal versions on a 64 bit operating system.
However, if you would like the 64 bit executables to run on your 64 bit operating system using the Standard GUI for Monte Carlo calculations, I have provided them as a ZIP attachment below. These exe files need to be extracted and copied to their respective application folders. They are generally:
Penepma.exe
C:\UserData\Penepma12\Penepma
Penfluor.exe
C:\UserData\Penepma12\Penfluor
Fanal.exe
C:\UserData\Penepma12\Fanal
Let me know if anyone has any questions.
-
We've been modeling continuum intensities in Penepma for a number of pure elements and compounds.
Ever wonder what the spectrum looks like for a 1000K seconds long simulation looks like after 275 hours?
(https://probesoftware.com/smf/gallery/395_11_02_22_11_28_40.png)
Now that's one smooth continuum... 8)