Submit through Canvas by Wednesday, 11th June 2025, 17.30 CEST.
Begin by rethinking and extending your requirements register, based not only on these two worksheets but also on the general scope of the project as discussed in our sessions. The register should now contain at least eight user stories, at least three personas, and at least one epic for each persona.
Draft a possible class structure for the end product in the form of an E-R diagram. This does not need to be the class structure that you are implementing right now. Recommendation: Make it so that your class structure would be sufficient to cover all the requirements that you have labelled "M" (must) and "S" (should), but not those labelled "C" (could) or "W" (won't).
It does not matter how you draw the E-R diagram. It is probably simplest to just draw it on paper and scan, which is completely OK. Some people have reported good experiences with Chowlk and OntoUML tools, which also are capable of connecting E-R diagrams directly with semantic technology. If you use a tool for this, the diagram notation will probably not be exactly the same as the one we had in the lecture, since there are many variants of this technique - that is also completely OK, you do not need to use the exact same notation as in the lecture.
Now extend your code base at least to the stage where you can apply Monte Carlo (MC) simulation using the Metropolis algorithm to your box with periodic boundary conditions (PBC) containing LJTS particles.
The Metropolis algorithm iteratively carries out test actions (or test moves or displacements) described in the lecture as follows:
If there are N molecules, one MC step or loop by convention consists of N test actions.
Above, there are two parameters: The temperature T, which has a physical meaning; it really is the temperature of the simulated system. The maximum displacement b. This is a technical parameter of the method, you can set it to b = 1/8. If you want to tune the b parameter, it is generally considered good if about half of the test actions are accepted, and half of them are rejected.
You can think of all sorts of output that could be interesting, but at least output the potential energy of the system. It can be a good idea not to output this after every MC step, but for example only once every 10 to 100 steps, to avoid unnecessarily large datasets.
You should now be able to run the scenario from the first worksheet. Set the temperature to T = 0.8. The simulation should reach negative potential energies very fast, but it will still take more MC steps until the configurations have become physically realistic; this stage is called relaxation or equilibration: You can recognize from the output that the (running average of the) potential energy is still changing. When the equilibrium state is reached, the energy still fluctuates, but it fluctuates around a stable average value.
Identify at least one useful way in which you can apply at least one of these techniques in your final code:
Do not use any of these just in order to be fancy. This should be grounded in one of the requirements. How will the use of any of these techniques help?