INF203 worksheet 1

Submit through Canvas by Thursday, 5th June 2025, 17.30 CEST.

General remarks on the worksheets:

• The worksheets 1, 2, and 3 are meant to guide you through the course toward the complete submission. It is not mandatory to do them, but if you do submit them in time, we will look at the status of your work and might give you some useful feedback.
• It is complicated and not the best way to explain all the ideas and concepts that we will use in text form as part of the worksheets. We will discuss them in the lecture and discussion sessions. So do ask all your questions about them!! We have enough time to talk it all through in detail.
• The literature listed on the website is meant as relevant works that one can cite when working on these topics. But you are in no way required to read it (or cite it), and you are also not expected to understand it unless you already have a background in this sort of problems.
• Submit the files you want us to look at and work with, and do so in the most suitable format; e.g., never submit code in the form of a PDF printout, but only in a way where we can actually try to run it. On the other hand, only submit LaTeX sources if you have specific questions about LaTeX that you want us to look into; otherwise, please include a PDF only. Include everything in one single ZIP file.

1.1 Group collaboration

Start to work together as a group; figure out all the logistics, specially in cases where not all members of the group can be present throughout the course, so that you can still contribute equally to the discussions and the collaborative work. Note that attendance in person is a formal requirement - we do not enforce it, but it is then the responsibility of those not attending in person to make sure that they are still able to participate in a regular way.

Set up at least a shared repository for the work on your code, for example using github. That will also make it easier to document that (or whether) all have contributed their fair share to the coding. You do not have to do all the work only via git, but are encouraged to use other environments for collaborative work in addition to that, for purposes other than the immediate code development.

1.2 Box with molecules at a random configuration

Start writing the code for your programming project. Use Python language, and write it directly in the form of *.py files that can be interpreted with the python3 interpreter (i.e., do not write it as a Jupyter notebook). In the first step, create two classes: One called Molecule, representing a point mass (each with unit mass m = 1) with coordinates in a three-dimensional volume; and one called Box, representing a cuboid control volume with periodic boundary conditions, containing the molecules.

Make it so that you the extension of the box in x, z and in y directions can be specified; i.e. the length L_x = L_z and the length L_y are parameters of the problem. For populating the box with molecules, divide it into three compartments, with a size relationship 2:1:2, along the y axis. That is, the middle compartment should occupy 20% of the volume, while the other two should each occupy 40%. The middle compartment is for the liquid phase, which has a certain initial density ρ'_init, and the two larger components are for the vapour phase, which has the initial density ρ''_init; these values are also parameters of the problem. Insert the appropriate number of molecules at random positions in each compartment.

Recommendation: Create three files: ./src/ljts/molecule.py and ./src/ljts/box.py for the two classes, and ./main.py for the script to be run through the interpreter. This is not a requirement, but if the codes have a similar structure, that will make it easier to compare codes, discuss them, and give you feedback.

For the present instance, create a box with the dimension 5 x 40 x 5, and use the initial densities ρ'_init = 0.73 and ρ''_init = 0.02. How many molecule objects does your code create?

1.3 Calculate the potential energy

Now you have created an initial configuration. Write code that, for the given configuration (i.e., positions of all the point masses), computes the potential energy E_pot of the system.

Here, the potential energy is given as a sum over all pairs of molecules E_pot = Σ_i Σ_j>i u(r_ij) where the interaction between any two molecules is given by the Lennard-Jones truncated-shifted (LJTS) potential:

• u(r_ij) = u_LJ(r_ij) - u_LJ(2.5), if r_ij < 2.5
• u(r_ij) = 0, if r_ij ≥ 2.5

Therein, r_ij is the distance between molecules i and j, and u_LJ(r) = 4 · (1/r¹² - 1/r⁶) is the Lennard-Jones potential. So LJTS means that the Lennard-Jones potential is being truncated at a cutoff distance of 2.5, and shifted by adding -u_LJ(2.5) = +0.01631689. All pairs of molecules i and j with a distance below 2.5 contribute to the potential energy, while the others do not contribute; each pair is counted only once, i.e., if you include the interaction between i and j, do not include it again in reverse order, between j and i.

Note that periodic boundary conditions are to be used; e.g., where you leave the box to the right, you directly enter it from the left, or in other words, a molecule directly at the right boundary of the box is very close to a molecule directly at the left boundary of the box. This applies in all three dimensions.

Make sure that you seed your random number generator e.g. using the clock (default seeding mechanism), so that every time you run the code, the positions and the potential energy are different. What values do you typically get for the potential energy? The value should normally be a very large positive number, since you have positioned the molecules at random coordinates (not physically realistic), where some are extremely close to each other. This is not a problem, because further on, we will implement a Monte Carlo algorithm, by which this high-energy state automatically relaxes to physically realistic configurations.

1.4 Requirements register

Set up a spreadsheet for requirements in the form of epics and user stories, following the methodology from agile requirements analysis. Define at least three personas, i.e., kinds of persons who may interact with your code in different ways. Specify at least four user stories. Classify them according to MoSCoW priority levels, i.e., must (M), should (S), could (C), won't (W).

Once you have set up your requirements register, maintain it throughout your project, adding requirements or improving the way in which they are formulated.

1.5 LaTeX document

At this stage, it is not necessary to submit any additional text document explaining things, but you can do so if you think it helps. For the final submission, you will need to submit a report/documentation. For this purpose, use LaTeX.

Index