Version 20160816 available, which namely includes 2D/3D pixel targets and cross-section interpolation in tables. See below.

Corteo is a Monte Carlo (MC) simulation program intended to make possible MC simulations of ion beam analysis spectra within a few seconds or minutes. It computes the trajectory of ions in materials, based on binary collision, central potential and random phase approximations. Computations are accelerated by extracting the scattering angle components in lab frame from tables indexed using the binary representation of reduced energy and impact parameter. It also uses the 'main collision' approximation: after computing the trajectory of the incident ion down to a certain depth, Corteo generates a scattered ion or a recoil in a wide cone oriented towards the detector. The trajectory of this ion is computed until it emerges out of the target, and its intersection with the detector is checked. Implemented techniques include RBS, ERD, RBS-TOF, ERD-TOF and coincidence of identical ions. Since version 20130715, Full RBS simulations are possible, that is, RBS simulations without the 'main collision' approximation, just as running SRIM for months or years, but in a few hours. And for that purpose, it is now easier to run corteo on computer clusters. It is also possible to simulate ion implantation, but results are usually not identical to SRIM, so be careful.

Version 20160816 allows to carry out simulation considering a target consisting of 2D pixels or 3D voxels. A bitmap (bmp, gif, png) containing a number of color can be loaded, each color representing a material which composition is defined the same way layer composition was defined. (The image can for example be derived from a micrograph, therefore severely constraining the solution.) A substrate layer can also be defined. This for example allows the definition of a rough interface below a layer since the substrate can have the same composition as one of the colors in the image. In the case of 3D images, they have to be in XRAW format as provided by the free voxel editor MagicaVoxel. The 20160816 version also allows interpolation of the cross-section in a table, and such table can be generated from SigmaCalc using a Python provided below.

See the Update section below where many details about the changes are given, a must-read! The program is available for download form this web site under the conditions of the GNU General Public Licence (GPL).


Documentation has been updated as of August 2016: Corteo20160816.pdf (4 Mb). This document describes in some details the theory and approximations behind Corteo, its parameters, input and output files, and its User Interface. You can also read the following papers:

Mailing list

If you want to receive e-mails about Corteo updates, please send an e-mail.


Corteo itself is programmed in plain C without a user interface. It can therefore run on any platform featuring a C compiler and is callable from any other program, namely its User Interface, CorteoUi, developed using Qt. By downloading and running the program, you understand that most of the files are distributed under the GNU General Public Licence and you agree with it.

Since version 20130715, it is no longer necessary to compute the scattering matrix and stopping tables from SRIM during setup. Instead, when the user runs the program the first time, CorteoUi ask the user to understand that the stopping tables included are generated using SRIM. Hence, the user should specify that when giving the details of its simulations in a paper.

Windows and Mac users can download an executable version of the program. Just download the appropriate zip file below, unzip it, and you are ready to go.

Linux users, see next section.

Compile Corteo

Linux users or those who wish to compile it for any reason:

  • Linux users can easily get a copy of Qt5 including QtCreator using their favourite package installer. This will also install all the necessary libraries and compiler chain. Also download any of the packages above, since they all include the source code.
  • Windows and Mac users, please download one of the latest Qt SDK Qt, which includes the QtCreator IDE. The Mac and Windows 32-bit versions use the GCC compiler.
    • As of August 2016, there is no Windows 64-bit version of Qt bundled with MinGW 64-bit. So if you need a Windows 64-bit version of Corteo20160816, you will have to install VisualStudio 2015 and compile it by yourself.
  • Run Qt Creator and open the file in the src directory.
  • Click on the hammer at the bottom left. Should work.

If you want to deploy the application:

  • Mac: run macdeployqt in the Corteo directory, which will add the required libraries to the package.
  • Windows: as of Qt > 5.2, run windeployqt CorteoUi.exe, which will add a bunch of DLLs and other files to the directory, but you may still miss a few (e.g. libwinpthread-1.dll, libgcc_s_dw2-1.dll, libstdc++-6.dll) so test it on another system where Qt is not installed before distributing it. The names and number of DLLs to copy varies depending on the Qt version you use.

Cross-sections tables

With version 20160816, Corteo allows to interpolate the cross-section or a correction to the cross-section from a table. See the selection box in each element description form in CorteoUi. Since in MC simulations, the cross-section maybe needed at any angle, the table must provide the cross-section correction at any angle and energy. Hence, Corteo Cross-section files (.ccs). The format of a .ccs is relatively straightforward: it containing an header with arbitrary comments but not starting with "Data:". This header usually describes the data and the paper to cite. CorteoUI will simply skip all the lines until it finds the line starting with "Data:". Then, on the next line, Corteo expects a line with 2 numbers: the number M of energies (rows) and the number N of angles (columns). The next line starts with a 0 followed by the list of N angles in degrees. Each of the M following rows then contain the energy in keV and the list of cross-section values (in mb/sr) or ratio-to-Rutherford (RR, no units). For a given collision, CorteoUi will look in the data directory for a specific filename. For alphas scattering of 12C and for a cross-section given as RR, the filename must be C-12-He-4-He-4_scat_RR.ccs. For protons scattering off natural silicon with cross-section given in mb/sr, the filename must be Si-nat-H-1-H-1_scat_CS.ccs, i.e. the _CS or _RR part of the filename reflects the units of the data contained in the file. The setting in the selection box in each element description form in CorteoUi has to be set accordingly.

Note that the cross-section correction/interpolation is applied only after the simulation itself, by the user interface. Power users who directly use the simulation engine (corteo) output have to carry out this computation separately.

Cross-section for p-p coincidence

Coincidence practitioners can download a table containing the cross-section for p-p coincidence. Data are obtained from the group at Universitat der Bundeswehr - Munchen. Please cite the following paper if you use these data: M. Moser, P. Reichart, C. Greubel, G. Dollinger, Nucl. Instr. and Meth. B 269 (2011) 2217.

The file must be placed in the data directory.

Script to create a table from SigmaCalc

The main available source of computed/estimated non-Rutherford cross-section data at any angle is the SigmaCalc database developed and maintained by Alexander Gurbich. The website specifically forbids distributing its data, which are computed on-the-fly (i.e. at each download) so Corteo users will find below a script that allows them to download a series of cross-section files at different angles, the script then generating a .ccs table to be used by CorteoUi. The table generated contains the header of one of the files downloaded from SigmaCalc for reference. Please cite that info when you use these data. And please remember that it is forbidden to distribute these tables since they contain the data from SigmaCalc website.

Here is the script. In runs only in Python 2.7 and requires a number of libraries; see the import commands at the beginning of the script.

The .ccs file generated must be placed in the data directory. The user has to check in the file header that the units were indeed "rr" (that is, ratio-to-Rutherford), and append "_RR" to the filename, before the ".ccs" extension.

Generating the scattering and stopping tables

Although the version 20130715 comes with scattering tables already computed, the user may want to generate new tables. One particular reason is that the scattering matrix that is included considers the ZBL (Universal) potential. One could want to try computing with a different screening function. From the command line, run corteosetup without argument; it will show the different options. Choices of screening include: none (i.e. plain Coulomb potential), Lenz-Jensen (on which the Andersen screening is based), and Universal (i.e. ZBL).

Would the user want to generate again the stopping tables:

  • Copy from SRIM SR Module directory the following files to the Corteo main directory : SRModule.exe, SCOEF03.dat, SNUC03.dat
  • Linux and Mac users have to install wine
  • Run the corteosetup program from the command line, specifying stopping as the argument. This will compute stopping power tables of each element in all elements. By doing so, you understand that you are using SRIM stopping powers for the simulations.

Running on a cluster

CorteoUi, since version 20130715, includes two new buttons at the top right of the parameters panel. These buttons are intended to make easier running long simulations (such as Full RBS simulations) on a computer cluster and reading back the results in CorteoUi. The 4th button will save the corteo input file but will not run corteo. The 5th button will read the file corteo.detect resulting from running corteo for an IBA simulation.

One aspect important to understand when running on a cluster is that corteo (the simulation program itself, not the UI) is multi-threaded but relies a lot on central data shared by the different threads, namely the scattering matrix and the stopping power. This information is read by all thread from the same memory. More specifically, corteo supports threads but not information transfer between nodes such as MPI would provide.

So the way to run corteo on a cluster is to run an array of jobs, each initialized with a different random seed. If the user wants to run on 100 cores of a cluster featuring 4 cores per node, in the CorteoUi/Compute panel, he/she should specify 4 threads (i.e. a number of threads equal to the number of cores in one node) or 8 threads if the core supports hyper-threading, then save the corteo input file using the 4th button.

Then, the user has to upload on the cluster the file as well as the src/corteo directory. On the cluster, he has to compile corteo with the compiler specific to the cluster. For example, if the Intel C Compiler (icc) is available (which accelerates computations by 5-10% over gcc), one can compile corteo with the following command:

  icc  -o corteo src/corteo/constants.c src/corteo/corteoindex.c src/corteo/corteoutil.c src/corteo/corteo.c src/corteo/corteomatrix.c src/corteo/randomx.c src/corteo/corteodedx.c -lm -lpthread -O2

Then, to run an array of jobs using qsub or the like, prepare a file containing infos similar to this (usually varies a bit between different systems).

#PBS -l mem=1000mb
#PBS -l walltime=15:00:00
#PBS -l nodes=1:ppn=8
#PBS -j oe
#PBS -W umask=022
#PBS -r n
#PBS -t 25-49
#PBS -o FilenameForStandardOutputOfThisRun.res
cd /somedirectory/username/directoryWhereCorteoIs
./corteo $PBS_ARRAYID

In order to estimate the walltime, the user can run a single simulation with 1/100th of the number of simulated ions of the simulation he/she actually want to run. (Also check how much data is produced during this test, so the cluster is not overwhelmed with data during the full run.) nodes is set to 1 because each job will run on one node (no MPI). ppn is the number of processor per node; the number of threads in should be set to this value. The -t switch specifies the index range of the array of jobs that will be submitted. In this example, the job ID will range from 25 to 49, each running on 8 cores, for a total of 200 cores. In the last line $PBS_ARRAYID is passed as an argument to corteo, which will use this value as a seed to initialize the random number generator of each job.

Keep in mind that running 15h on 200 cores may exhaust your priority for submitting new jobs rather quickly!

Bugs and features

  • There is one feature regarding the screening that should be understood: the screening selection in the CorteoUi/Simulation panel only applies to the 'main collision'. For the slowdown process, the screening function is determined when generating the scattering matrix using corteosetup. The scattering matrix provided with the installation packages uses the Universal (ZBL) screening function. Hence, corteo can uses two different screenings during the same simulation: one for the slowdown, and one for the main collision. This is a feature. The bug is that such screening can be selected even for 'Full RBS' simulations, but it is meaningless. In this case, the only screening function that applies is the one used to compute the scattering matrix. It will be corrected in a future version.
  • In versions prior to 20160816, A parameter in the ZBL screening function was set to 3.0 instead of 3.2. The effect is of a couple of percents. Thanks to Kai for spotting it.
  • If there are many detected particles resulting from a simulation, the file corteo.detect will be huge. Be careful. Likewise, this file can be long to load and there is no message after the end of the simulation indicating that CorteoUi is loading this file. Be patient.
  • Other bugs include the fact that implantation simulations are probably not very reliable, and I did not have the time to dig into it yet. See Iradina for something more reliable.


Update 16 August 2016: With this version of Corteo, it is now possible to consider 2D (pixels) and 3D (voxels) targets. An image containing a (limited) number of color can be loaded, each color representing a material which composition is defined the same way a layer composition is defined. (The image can for example be derived from a micrograph, therefore severely constraining the solution of the fit.) A substrate layer can also be defined. This for example allows the definition of a rough interface below a layer since the substrate can have the same composition as one of the colors in the image. 2D images can be in .bmp, .gif, .png format. 3D voxel images loaded in CorteoUi must be in XRAW format as produced with MagicaVoxel (free, Mac and Windows versions available). The image format used by the simulation engine corteo is a much simpler text file. See the manual for a description.

The 20160816 version also allows interpolation of the cross-section in a table, and such table can be generated from SigmaCalc using a Python script (see above).

Update 15 July 2013: This version of Corteo brings no fundamental chances to the physics. It is rather an internal rework of how things are processed. In the previous versions, corteo could run the simulation of one isotope of one element in one layer at the time, and CorteoUi was controlling the process to obtain a complete spectrum by starting several simulations. In the new version, this is rather achieved by corteo itself. The purpose is that the complete simulation can be carried out in one run on a separate machine, e.g., a computer cluster. The other important aspect that has changed is that rather the producing spectra, corteo now produces an event list. If the parameter 'writedetails' is set to '0' in (as CorteoUi always does), it gives the detection energy and a few other values such as the cross-section and angle at collision, depending on the technique selected. For details, see the first line of corteo.detect, the file produced by corteo. The power-users may want much more details, such as the locus of the main collision, the impact position on the detector, or the depth and angle of the 5 most largest scattering events in Full RBS. This is obtained by setting 'writedetails' to something else than '0' in Again, see the first line of corteo.detect for details. (The column titles in the first line are usually the name of the variable that are printed and are hopefully self explanatory, but in doubt, see the corteo.c sourcecode which will tell you precisely what is the meaning of a variable.)

Be careful however, it spits a lot! The demonstration simulation when you start CorteoUi the first time generates a 50 Mb file. You can easily reach Gb of data if many, many events are detected, especially on a cluster.

Because corteo generates a list of events, the spectra are computed when reading the corteo.detect file. Hence, the user can change the detector calibration or resolution and simply reload the results of the simulation by clicking the 5th button. Spectra can also be generated in another software by generating a histogram where each event increment a bin by the cross-section. The spectrum then has to be convoluted for the detector resolution.

Last but not least: this version features the possibility of carrying 'Full RBS' simulations, that is, following the trajectory of billions of ions and detecting them, therefore avoiding the 'main collision' approximation: each detected event bears an equal weight. It is especially useful to simulate the contribution of many low-angle scattering to the spectrum background. More details to come, hopefully in the proceedings of IBA 2013.

Update 27 May 2009: Corteo20090527 repairs two important bugs, but contains several new developments. It should now be quite reliable as it has gone through most of the intercomparison exercises and gives results virtually identical to SimNRA/NDF when deflections are "turned off" during atoms slowdown. (A detailed intercomparison will be presented at IBA 2009.)

  • Bug: beam spot size was 10 times too large in the simulation. (This is the kind of mistake I was afraid to do when developing a GUI.)
  • Bug: whole spectrum was off by a factor 1/cos(angle of incidence). (I have no idea why this factor is needed, but it has to be there to "intercompare" correctly!)
  • New: There is now the possibility to use a cross-section computed using not only Andersen screening but also cross-sections computed using the Universal potential and the Lenz-Jensen screening. The comparison will also be discussed at IBA2009. However, the computation of the later two slows down quite a lot the computation.
  • New: Roughness (Gaussian thickness distribution) can be specified. Feature: if a negative roughness is specified for a layer, the thickness added to a layer will be subtracted to the next and conversely. This is useful to simulate interfacial roughness in otherwise flat layers.
  • New: If the user load data in counts vs channel, he/she can apply the displayed calibration on the selected data.
  • Secret feature: user can "turn off" atom deflection by entering a negative mean free path. The default simulation that loads at first run corresponds to intercomparison exercise S1.

Update 20 February 2009: Documentation now available (see above).

Update 4 December 2008: This version of Corteo Corteo20081204 contains important bug repairs and new functions implementation:

  • A nasty bug was found in the way CorteoUi sums the different parts of a simulation. If an element in a layer had its concentration set to a non-zero value but was not selected/active, its concentration was indeed considered to normalise the spectrum of the other elements of this layer. For example, if you had a layer consisting of Si 1 and O 2, and you later uncheck the O “use this element” check box, the subsequent simulation will run for a layer consisting of Si only, but when the full spectrum is computed, the Si signal counts for only 1/3 of its actual contribution because the concentration of O is still taken into account.
  • The “simulate isotopes” checkbox is now enabled and the function is implemented: for each element, if desired, sub-simulations will be made for each isotope in proportion of the isotope fraction.
  • By checking the “list mode” checkbox in the last panel, you can obtain a list of all detected events saved in the file specified by clicking on the “list file” button. This is helpful if you need to do post-treatment of the detected event such as kinematics correction. This was not working properly but it is now fixed.
    • In the case of an implantation simulation, the columns are: ion#, number of collisions, energy, position (x, y, z) and directional cosines (l, m, n) at end of trajectory.
    • In the case of an IBA simulation, the columns are: index, energy, position (x, y, z) and directional cosines (l, m, n) on the detector (in detector’s reference frame), and two factors that multiplied together represent the contribution of an event to the spectrum. It is important to note that not all events contribute equally, see here why. The index is usually +2, but is -2 when, in coincidence, the detected ion is the second particle.
    • Note that spectra generated with list files still need to be convoluted for detector energy resolution.
  • Before, the spectrum of each simulation was loaded, and the user has the option to sum the contributions of the different sub-simulations by checking the “sum same element” checkbox. This behaviour is now reversed: the program generates by default the sum of sub-simulations (RBS: sum of all simulation since there is only one detected element; ERD: one sum for each detected element) and the checkbox is now named “also load separate spectra” and allows to also load every sub-simulations, including isotopes if selected.
  • A problem concerning rectangular virtual detectors is now fixed.

As usual, Windows users that already installed a previous version can only replace the executables.

Update 18 September 2008: Correction of a glitch : on relatively slow computers, the simulation takes too long to start and the user interface displays a (meaningless) message: "Can't find number of threads".

Update 17 September 2008: Previous version contained a bug that made simulation endless when a foil was specified (thanks Zdravko). A bad choice in random list lengths is also corrected, and the lists should now cycle only every 7.5x1015 collisions. For those who have seen my poster at the IBMM in Dresden, this was responsible for some features in implantation profiles. That version was also not compilable neither runable under Linux due to several mistakes. The new version should work properly under both Linux and Windows, although not tested under Mac. It includes the necessary modifications to run SRIM's SRModule using Wine under Linux. The steps below have been updated for Linux users. Windows users that have already installed the previous version may only copy the executables (*.exe) of the new version to the existing Corteo directory, instead of going through the setup process.''

Over versions prior to 17 September 2008, Corteo features:

  • a User Interface
  • simulation of coincidence spectrometry
  • energy difference discrimination for coincidence spectrometry
  • simulation of ion implantation including full cascade (still under test, does not work properly namrly for hydrogen)
  • compound correction factor for the stopping power (not fully tested)
  • arbitrarily positioned and oriented rectangular, elliptical and annular detectors
  • virtual detectors that can be elongated in only on direction (e.g. in the direction parallel to the surface for measurements at grazing incidence).
  • the program is now parallelized to run on multi-core processors: 4 cores, 4 times faster.


Feedback is strongly appreciated. If you run into problems, please send an e-mail giving the best description possible, indicate what version you are using (name of the zip file), close the Corteo user interface, and attach the Corteo.cml file to your message.

Good luck,


Editer page Historique Version imprimable Editer menu