The project work is not compulsory, but strongly recommended, and will count for 40% of your final mark. The deadline to hand in the project work is the 20th of April. We plan a presentation of the project with feedback on the work done on the 16th/17th of April.

This project aims at developing experience in implementing and experimenting with finite difference discretizations of PDEs. This is a very important goal of this course.

The project is a group assignment, and students should work in groups of three to four.

Students should aim to register groups by the end of this week (i.e. 25th Feb) - please send me an email with a choice of your favourite 3 equations from the list below, together with the desired groups. If you are only 2 or alone, let me know and I will aim to help form a group for you. This may take slightly longer, I hope to have these formed by Monday 26th Feb.

Your task is to choose a PDE and find out as much as you can about the problem. Then propose a finite difference discretization of the equation (motivated by analysis), and implement your method as efficiently as possible. A List of PDEs to choose from has been provided - if there is an equation you are desperate to study that is not on this list we may be able to accommodate this, let us know.

Most of the problems have an intended real world application - we hope that this can help make the problems more approachable and interesting, and also reflects that most PDEs are studied with some applications in mind. We encourage you not to lose sleep about modelling matters, but it will be a nice bonus if the plots you display give an indication of what the equation is representing.

The project aims to encourage self-sufficiency and creativity by its open nature - we have not provided an enormous amount of information, and students are expected to do their own research into the problems. We are aware that this may be intimidating and will be available to provide guidance, particularly in the early stages of the project.

1. Scientifically written report
   • Please write your candidate numbers on your report. Do NOT use your names or student numbers.
   • You should communicate clearly how you have solved the different tasks (see Evaluation below).
   • The maximum number of pages is 8.
   • Use an appendix if you have some extra material you absolutely need to attach to the report, for example extra pictures or pseudo-code (but be advised that we will probably not read through the appendix)
   • In the conclusion section it should be clearly stated who did what. It is important to note that all participants in a group share equal responsibility for everything the group hands in. Every participant of a group should know and understand everything the group has done. If the members of the group agree that the work has been distributed evenly, simply write that each of the group members has contributed equally to the project work.
2. Code files
   • You can send multiple files BUT it should be easy enough for us to run the code (make a README file with the instructions of how to run the code).
   • The code will be used if we need to check parts of the report that we do not understand and in order to see how efficient your implementation is.

Send your report (in pdf format) and code files by e-mail to us within the deadline.

You can get a total of 40 points.

• Implementation. The main goal of the project is to gain ability in using finite difference methods in practice. You should show your ability to set up the problem appropriately, choose one (or several) finite difference methods to obtain a numerical solution, and display the results. Comment on the results - do they look like you would expect? Max score for this task is 20 points.

• Analysis. You should motivate your choice of method and provide an analysis of the problem justifying the choice of the finite difference discretization and possibly proving the convergence of the numerical scheme (at least for a simplified, but relevant test problem). Max score for this part is 10 points.

• Numerical verification We want to ensure that you have learned how to design numerical experiments to check the accuracy of your code, and numerical evidence should be included in the report. For example, this can be achieved by computing the error relative to a known solution of the problem or to a reference solution produced by running the programs with very small space and time step-sizes. In particular numerical results showing the order of convergence of the implemented numerical discretization should be provided. Max score for this task is 10 points.

The evaluation will take into account the degree of difficulty of the problem you have considered.

The presentation will be an important step in the evaluation process. You will be asked to present your project in general and to explain how you handled these two different tasks (correctness of the implementation, and analysis). This is mandatory. If you are sick, you should provide a medical certificate to Stian at the office of our Department and inform us. We will arrange an oral discussion of your project work at a different date.

• Release of project, formation of groups: 20th of February, groups to be formed by the end of this week
• Oral presentation of preliminary work: 16th/7th of April
• Deadline for handing in the final report: 20th of April

Group composition and equation choice are based on information provided at registration, if this was subsequently changed and I failed to notice I apologize in advance!

Generally the quality of the presentations was good, and I have the impression that where there is some work remaining most of you are reasonably clear regarding what needs to be done. Nonetheless, a few general comments:

• For those implementing multistep schemes (such as the leapfrog method): beware that the Lax-Richtmyer equivalence theorem given in the course does not cover multistep methods. Indeed, the convergence analysis is somewhat more complicated, although a Von Neumann stability analysis and truncation error estimates remain the underlying tools. For those interested, there is a discussion in chapter 10 of the Strikwerda book, although this is perhaps a bit difficult to follow. It will suffice to give the stability/consistency results and then provide a reference to such a source.
• The order of convergence of a given numerical method cited in textbooks often assumes certain smoothness requirements of the solution, particularly those studying nonlinear hyperbolic equations may find that schemes end up converging with a lower order than expected. Unfortunately it is not always easy to distinguish an order reduction due to properties of the equation from order reduction to programming error!
• For schemes such as Lax-Friedrichs which are highly dissipative, it may be necessary to fix a relation k=k(h) between step sizes in time and space in order to find meaningful convergence plots. In some cases this is even a theoretical requirement to obtain convergence. When doing so you will obtain only a single plot instead of separate plots for convergence in space and time.
• Be aware that convergence of a scheme in one norm does not always guarantee convergence in other norms, and certainly not the same order of convergence.
• For those implementing semi-discretisation: stability analysis of ODEs has certain nuances that may not be clear, for instance whilst the backward Euler and trapezoidal (Crank-Nicolson) are in some sense both unconditionally stable, the backward Euler method is considerably more stable (it satisfies some strong stability definitions that the trapezoidal rule does not) and in practice may give better results despite being lower order. Also, particularly when the evaluation cost of a time step is taken into account, higher order numerical schemes are usually less stable than lower order schemes, not more.