Based on feedback from 2012 and onwards

1: Students getting the right things out of the course:

I was really scared of that course since I get easily intimidated by people who seem to understand everything about computers. But the course was very well done, friendly to complete beginners. I started spending a lot of time on the assessments, more than I needed to, just because I saw it as a great challenge and I enjoy the moment when it works. For bonkers for example I wrote my own program (not the website one) using a different approach and now I am really proud of myself and see myself doing more c++ in my spare time. Well done
Really good, completely changed my opinion that programming would be really dull.
Thanks for a brilliant and highly useful course on computing, which was totally new to me.
I thought c++ was much better than matlab

2: Proof that not all students listen in lectures:

I am not interested in C++ and you should not impose it to everyone.

3: Are you self asessing correctly?

First 4 sessions are childish next ones are too hard.
I feel more should be done to warn students of the increasing volume of work required for this course. I may have decided differently on my extracurricular activities had I known the time required for it. Moreover, I could only attend one afternoon per week, and the short two hour slots were not long enough to get a good grasp of the later assessments.
Even though the course is self-assessed I found the change from session 4 to session 5 too large. I spent 2 .5 hours on session 4 and nearly 8 on session 5 which I still haven't come up with anything very good for. I think I needed to be a bit more experienced in running longer programs before trying to use them to understand new things about Physics.
I think it would be more helpful to allow more time for the last two sessions, or build up more gradually towards them. As they have been moved to this term they have to be completed before we are lectured on the physics involved which means more time needs to be allowed to help us understand what we are trying to do. I found that both of the last two sessions needed 2-3+ afternoon sessions to complete, in addition to the two hours preparation time. It was especially hard to find this time towards the end of term when workloads for other subjects and supervisions also seemed to be increasing.
The 'physics aims' of session 5 and 6 were quite tedious as we know most of that physics already and it didn't teach me anything new.
Personally it took me a long time to do the last two assignments which were worth more marks, due to how long they took to debug, although I appreciate that worked examples were provided and would have been a shortcut - perhaps a warning would be appropriate! However, it was my personal choice to do so.

4: You learn from demonstrators, each other, the handout, the course website and google. You don't learn from these lectures or from me.

Good, helpful demonstrators
Treated you on a level, were very helpful and understanding, with plenty of patience!
The demonstrators are lovely people and they were always there to help me. I asked a lot of questions and they were all answered. Very competent people
For the most part, the demonstrators were very helpful, staying after the time period for their obligation to stay had ended. Without them I would have struggled.

5.1: I strongly disagree with this one:

We had only two computing lectures so there aren't much things to say. It might have been better to acturally have c++ lectures rather than just an introductory lecture.

5.2: This person didn't understand the tune either:

There were two lectures that seemed to be focused on creating interest amongst students - the unicycle programme, for example - rather than giving a systematic introduction to C++. I would say I learnt very little of practical use in the lectures. If the aim was the latter, the lecture course failed its objective. Though the lectures were interesting, and well-delivered, I did not leave them thinking I had the basic knowledge required to start programming.

6: Don't wait until AFTER the course has finished to comment on the lack of demonstrators on a certain day. Report it in week 1 or 2!

Need more demonstrators, it takes too long for the two of them to address everyone's concerns individually.

[ NB - We now have three demonstrators per day. Previously had two per day when this feedback was written.]

7: Things we got wrong and should be fixed for this year. Mea culpa.

The worked examples did not respect the latest updates of GNUPLOT (this comment was reported by many students)

8: More proof that people do not listen to (or recall) everything in the lectures, and made no attempt to read the gnuplot examples pages on the website

GNUPLOT instructions were far too brief, from the tutorial I can barely do anything with it. [CGL: That's because gnuplot usage instructions are given on the course website under the gnuplot links. Go BACK to find them.]
GNUPLOT was probably the only thing that wasn't explained fully enough in the manual. [CGL: That's because gnuplot usage instructions are given on the course website under the gnuplot links. Go BACK to find them.]
A possible adaptation for next year that might help: In the examples on the course page there are several examples of movies that universally work by a ``plot t lines of a file, where t increments over time''. The way in which this t is incremented is a bit cumbersome, and involves a file recursively loading itself (and hence a total of two files for any one movie). However, gnuplot 4.6 supports a form of for loop: http://www.gnuplotting.org/gnuplot-4-6-do/ which allows the same thing to be achieved much more easily, I think.

Unexplanation of the unexplanation

very good handout, but the things left unexplained should not have been left unexplained

Well intentioned but wrong

Fantastic! It was so refreshing to have a lecturer enjoying giving the lectures, he had great energy and made us comfortable by going away from the lecture notes, which we were to read in our own time, and focus on the applications of computing... He differentiated a cat??!!

Long and thoughtful comments buried in assessed submissions

When I began the work for Session 6, I felt like I could see the light at the end of the tunnel. The end was nigh. I decided to follow the wise words of our dear leader and to use the code that was readily available for us online. My computing objectives for this session were to be able to understand what someone else’s code does, and to be able to modify it in a useful manner. On top of this, my physics objectives were to understand a bit more about collisions and gases – however it is worth noting that it was difficult to compare our results to theoretical predictions given that we have not studied thermodynamics yet, and my memory of the bare bones that I learned whilst at school is shoddy at best.

In any case, persevere I did. I took the (admittedly rather beautiful) code available in the script Bonkers1.cc. Initially I attempted to try the 4th suggestion – having the right-hand wall moving at constant speed. However, after a lot of blood, sweat and tears I was unable to get this to work – I feel like there was an issue in the in the collide function, which didn’t like walls moving. Oh, well.

I decided to focus my efforts on suggestion number 5 – having two sets of small molecules to either side of a large “piston”, which was meant to model having two gases with different KEs, separated by said piston. I modified the script so that I could play around not only with the piston’s mass, but also its velocity and radius, to see what the effects would be. As expected, if I started the two gases with different KEs, eventually they settled down to the same temperature (I compared the temperatures by using the kineticEnergy function in the script, knowing that 3/2kT = Ẅm (vrms)^2). I then proceeded to give the piston a very large velocity relative to the smaller molecules – a system that is meant to simulate adiabatic expansion and contraction of two gases. In these systems we expect the energy of the compressed gas to increase very quickly, and that of the expanded gas to decrease very quickly. As expected, this was observed in the data plotted, with the KE of the gases inverting each other (i.e. as one increased, the other decreased and vice versa). I was also delighted to see that the Kinetic Energy of the overall system remained constant throughout – a lovely check that the system was modeled accurately, and a nice change from my programmes from the previous session. I was also able to set up the system such that the piston oscillated roughly constantly before reaching equilibrium – the time period was constant, with the piston varying in position over 4-5 units. Unfortunately my knowledge of thermodynamics was too basic to be able to calculate the expected oscillation frequency, so I was unable to compare the results I obtained with a theoretical value. It was also slightly frustrating having to go and adapt the gnu10/11 scripts every time I altered the number of particles in the system – I am sure there would be a more efficient way of doing this, and I am sad to say that gnuplot has been the bane of this computing course for me, so I may have to investigate this further as well over the holidays.

I then modified the system further so that I had not one but two pistons, to see if I could model the so-called “Zeroth Law” of Thermodynamics. (This script is the one that I have submitted, along with my edited gnu10/11. I also added in another kineticEnergy function (which can be ignored) when I was trying to find a quick way to work out the KE of the gases, but the computer didn't seem to like what I came up with, as it kept on giving me KEs of zero.) The law states that, if two distinct gases are in thermal equilibrium with a third, then all three are in equilibrium. To test this, I started the pistons off with low velocities, but gave the middle (of three) gases lots of KE initially. As expected, once equilibrium was reached the three gases had the same KE. I then tried out the system with both pistons starting with very large velocities. As expected from adiabatic processes, the compressed gases again had large increases in KE, with the opposite holding for expanded gases. It was interesting to see the behaviour of the middle gas, as this was dependent on the relative speed of the pistons. In this system it took longer to reach equilibrium, and so in most simulations I ran the system did not reach it, but the behaviour prior to this was as expected.

I have to say, I have enjoyed getting to grips with c++, and I think that what we have been taught has been useful. However, I take exception with a couple of points on the course, for example the fact that we haven’t been taught thermodynamics prior to doing this session, or the fact that the course is crammed into first term, with little regard for people wanting to pursue computing further but who are unable to find the time during term time. It would be better to replace some of our experimental practicals (some of which are SO pointless) with computing sessions – in seven hours, with demonstrators on hand, we would be able to learn a huge amount and would have more freedom to explore c++ a bit more. It would also replace something redundant with a highly valuable, transferrable skill.

Over and out.

[ Emphasis added by CGL. ]