In electron spectroscopy matter is examined by radiating it with a bright light and measuring the kinetic energy of electrons that come off it. When the photonic energy of light and kinetic energy of the electrons are known, they can be used to derive the amount of force that was required to break off the electrons. This provides valuable information about the matter's electron structure, and its chemical and physical properties. This phenomenon where photons break off electrons is called photoionization, and the broken off electrons are called photoelectrons.
In this course project you'll learn how to read data into a program and how to perform small operations on the data, and how to plot data using Python libraries. Your task is to write a program for analyzing the photoionization spectrum of argon. For this purpose we have provided you with simulated data where argon atoms have been ionized and the kinetic energy of broken off electrons has been measured.
This project requires you to use two third party libraries: numpy and matplotlib. There are multiple ways to install them. Windows installers can be found for both, and you can also install them using pip. There are also various full stack installers available in the internet (full stack means they install Python along with a bunch of libraries, usually replacing your "generic" Python installation). Please write a comment in your code if you use any such full stack installer because they might contain different versions of the libraries than those available generally. The virtual machines in our department's PC classes also should have both numpy and matplotlib installed.
You will find the data here. The measurement has been performed multiple times, and each measurement session has been recorded into a different, numbered file. The file names are in the format
measurement_i.txt. Each file contains rows of data with two floating point numbers. The first number on each line is the binding energy of electrons, derived from the measured kinetic energy (unit: electronvolt); the second number is the corresponding intensity (no specific unit; this described the amount of electrons measured with this particular binding energy). In each measurement file, the first column contains the same uniformly distributed binding energy values. Your program should add together the intensity values from each file. The purpose is to eliminate noise from the measurements.
Due to the measuring equipment, the spectrum has a linear background. Aside from the obvious peaks it looks like a downward sloping line. The background signal that causes the sloping should be removed before analyzing the spectrum. This can be done by choosing two points from the spectrum and fitting a line between these points. After this, at each data point, values obtained from this line are subtracted from the measured intensity values.
When analyzing the spectrum our primary interest are the two rather obvious peaks in intensity; in particular, their relative intensity. The intensity of each peak is obtained by computing their area by obtaining its integral. This can obtained by using the trapezoidal rule to estimate the integral. According to theory the first peak should have approximately double the intensity of the second one.
Your program needs to have the following features:
- Your program has a main menu where the user can choose between operations to perform. The operations are explained below.
- Load data: loads data from a user-specified location and reads it into program memory in a format that is suitable for processing. Should return one list for each column in the data. Remember to add together the intensities from each file.
- Plot data: this plots the current data (the user is prompted to load the data first if it hasn't been loaded yet). You can plot the data using matplotlib. The figure should look like the one below.
- Remove linear background: removes the linear background from the data as described above. The user is prompted to provide two points, and the line is fitted between these points.
- Calculate intensities: prompts the user for two sets of x values; the start and end points of each peak. The intensity of each peak is calculated, and their relation to each other is also printed.
- Save figure: this feature allows the user to save an image of the current plot. It prompts the user for a filename, and then saves the figure. matplotlib provides you with the necessary features to do this.
You should name the axes in your figure with appropriate names. There are tools for doing this in matplotlib.
We like collaboration on this course. These weekly nice little exercises are actually made in cooperation with several different assistants. It's also probably much more pleasant to solve them together. Your friend may have a better understanding about something, and two pairs of eyes spot bugs more easily anyway. In most cases you realize your mistake when you start to complain to someone that your program doesn't work. Usually things work more smoothly in your head, compared to what it sounds like when you start to explain it to someone else. That's why we don't by any means want to take away the joy of collaboration from you and we actually encourage you to ask help not only from assistants, but your friends as well. We are quite good in giving advice, but your friend is more likely on the same wavelength with you and may be able to give you even better advice than we can.
However, on this course it's required that every student learns to write programs independently. This aspect is good to keep in mind when you are writing code with one or more friends. You shouldn't use code in your program if you don't know what it does. Ask your friend to explain if you don't understand the given piece of advice! Of course, if your friend is a good team player and has read this guide, then maybe he or she can instruct you in a way which you too understand what the code is doing. There's a tedious side to copying someone else's code: everyone loses. The one who copies doesn't get any smarter when he or she can't understand what the copied part of the code does, and the one who let his or her code to be copied can't get to deepen his or her understanding of the issue by shaping it to a more comprehensible format.
Unfortunately these cases are encountered annually, so along with the beautiful thoughts we have explicit and easily understandable rules concerning collaboration on this course. By following these rules you avoid problems - problems usually means, that your course credit can be postponed to the undefined future while the case is being resolved. In the worst case you may have to retake the whole course. These rules can be wrapped up to a few sections:
- Don't copy code from anywhere or anyone and make sure you understand everything you write to your program
- Always report if you have collaborated with someone. There's an individual text field for this in file tasks
- If you take an example from somewhere else (internet), tell this in comments above the code and tell where you found it
Your course work will be accepted if it fulfills the core requirements specified in this document. Unless your code is extremely obnoxious, any fully functional programs are accepted. In addition to submitting a functional program, you are also required to reserve a 15 minute review session with a course assistant. In this review session you will be asked questions about your code and if you fail to answer properly, you will be required to study your code and reserve a new review session. We are required to make sure students submit code they have implemented themselves, but that's not the sole reason. Simply put, no programmer should never ever submit code they don't fully understand. Remember: You are always responsible for your code.
Quality of the code¶
On this course we aim at teaching ways to produce good code, and we expect to see the results in the final assignment. Barely working implementation doesn't guarantee passing the course if the code is awful; correspondingly you can compensate a slightly incomplete implementation with great quality. There shouldn't be any problems if you've read the course material through with some thought. Below is some guidelines how the different quality factors are graded. The is to get at least "good" from every category.
Variables and naming¶
- bad: It is impossible to deduce what the variables and functions are for or what they contain based on their names.
- good: The names for variables and functions are usually informative about what they are used for, although some of the names can be a bit off. Variables can be named with several different languages and/or the naming convention is not very consistent.
- excellent: The program has a logical and consistent naming convention. The number of variables is low, and assignment to a variable is not used where it's not needed. Similarly, assignment to a variable has been used to simplify long lines of code.
- bad: No use of
else-clauses or is very lacking.
oroperators are not used or understood. As a result, the use of conditional statements is very shaky and might work more by accident than by purpose.
- good: Conditional statements are mostly sensible. Proper use of
else, nested conditionals, and logical operators. Conditional statements can however be a bit shaky or be needlessly complex or long.
- excellent: Conditionals are pretty and succinct. All the previously mentioned tricks are used in a way that they improve the readability of code. They make it possible to detect different states so that the user can be told what is happening in the game.
Data structures (tuples, lists, and dictionaries)¶
- bad: No use or very little use of data structures. This is apparent in the code by having a lot of numbered variables. The few data structures are misused in horrible and naughty ways.
- good: Lists and such are used to create sensible data structures in places where they are obviously needed. In places where the need is not as obvious, there might be use of numbered variables or other comparable means.
- excellent: Data structures have been used in places where they are obviously needed and in places where they make the code clearer and more succinct. Nested data structures are also clearly understood.
Loops and iteration¶
- bad: All loops are made in the same way, forcibly if not else. For example all loops might be made with a
while True, even if the loop clearly iterates a list.
- good: The student is able to recognize when to use
whileand when to use
for. The use of loop variables in for loops might be a bit unclear, or loop creation in general is not optimal.
- excellent: Loops are efficient and the number of iterations in them is as low as possible. Loop variables are used well, especially in the case of nested datastructures. Tricks such as enumerate are used where proper.
- bad: No functions at all, or used just to use functions. No division of code into logical pieces. Using global variables instead of proper arguments for functions.
- good: Functions divide the program into logical segments, even if the segments can be a bit too large at times. The use of arguments and return values is correct. The use of global variables is low and only in places where it makes sense.
- excellent: Functions are divided so that they are all short and limited in their purpose. Only the main function can be a bit longer and fatter, but even it should be within sensible limits. The passing of arguments is sensible in the way that everything does not have to be passed everywhere. If there is any use of global variables, they are clearly in places where they make sense.
- bad: No modules, the program does not function the proper way. Zero points can also come from using
from importeven when it does not make any sense.
- good: The required modules have been found and are used properly.
- excellent: The program uses some more complicated features of modules (for example the formatting in time) or a module has been used to create additional features. The program has been divided into modules of its own, if needed (in the case of clear and succinct code, usually not needed).
- bad: Program has no error handling, and every time something goes wrong, the Python stack trace is shown to the user. The program also doesn't solve erroneous states without breaking, which can result in a locked up or inescapable state in addition to crashing.
- good: Error are handled properly with the exception of some exotic cases. The user always has some sort of clue how to act so that the program does not report an error. Error handling methods might not be the most optimal.
- excellent: Error handling methods have been selected so that the user always gets the best possible information in the case of an error.
try-dblocks mostly contain a minimal amount of code. The program can deal with even the exotic error cases.
- bad: No use of files or reading files is done with some odd way (that was not taught on this course). Alternatively, the code only writes files but does not read them.
- good: Files are read and written in some way that the statistics requirement is filled. Alternatively the game has some other way to use files, like saving and loading.
- excellent: Files are used intelligently so that anyone can deduce just by looking at the files how it should be interpreted by the program.
These can be thought of as extra achievements.
- Readability: The readability of code is very good. This means that names, spaces, and such follow the conventions and guidelines taught on this course. In addition the code has been commented where necessary, and mostly in function documentations.
- 'No bugs: If the assistant testing your program cannot get it to crash or function erroneously (for example to break the rules of Minesweeper) in any way.
- Usability: This is awarded to a game where the user does not get frustrated with the user interface. The usability should be good and the presentation of game state should be clear. For example making a move should be possible with just one short input.
- Joker: This achievement can be awarded for a neat additional feature, the proper use of a tool not presented on the course, or a feature done in an exceptionally funny or neat way.
Returning the work¶
In order to pass the course the student must undergo a 15-minute personal evaluation session with the course assistant who revised his or her work. You can book your evaluation time with a form which will be added to this site at the end of the course. If you want to return your assignment before that, you have to book your session via email: firstname.lastname@example.org. Also tell us why did you decide to do your course work beforehand and where have you learned the required skills to do the it.