The University of Waikato - Te Whare Wānanga o Waikato
Faculty of Science and Engineering - Te Mātauranga Pūtaiao me te Pūkaha
Waikato Home Waikato Home >Science & Engineering & gt; Physics Stop
Staff + Student Login

December 2012 Archives

Blogging has ground to a halt in recent days, as I try to get other things done, such as research proposals, reviewing a PhD thesis, supervising a summer student, and attending numerous parties. I'm off on holidays very soon, but will be back early January.

I'm currently grappling with an ever increasing parameter space in one of our computer models. These parameters are for things associated with various neural processes - such as how quickly does release of a particular neurotransmitter occur, and under what conditions? There are a lot of things we need to know, but in some cases they haven't been measured very well.

The solution is easy. Consult some friendly experimental neuroscientists. Which we did last week. But that didn't help, because they didn't know either. In fact, it made it worse, because they drew our attention to another raft of things that we should be considering, but didn't have much data on either. Indeed, they looked to us to help reduce their parameter space through our modelling.

I get the impression that there is very little known at the cross-over between physics and neurophysiology. A good reason to study it, then.

| | Comments (0) | TrackBacks (0)

I've worked on a lot of computer models of physics things for my various employers to date. Although I'd describe myself as primarily a physicist, I'm also a computer modeller - that's what holds together my work on mould growth in grain silos, dispersion of dust within pig-sheds, infra-red sensors, radar propagation, electrical behaviour of neurons, etc, which on the face of it are rather different (and some not obviously physics at all). Note that I don't claim to be a computer programmer - I don't produce fantastic memory-optimized whizz-bang graphics apps - what I mean by modeller is being able to take a physical thing (like flow of air in a pig-shed), produce equations that describe the physics going on, and then write a computer programme that solves these equations to produce a result that should describe something physical.

A big part of doing this is answering the question "how do I know my computer is turning out a meaningful result?" There are basically two bits to this question.

1. Verification. This is ensuring that my computer programme is actually solving the equations that I think it's solving, and doing what I think I've asked it to do. One small mistake - e.g. a bracket ')' in the wrong place, two lines of code executed in the wrong order, etc., and the answer might be different. I need to be sure that I'm getting what I think I'm getting.

2. Validation. Here's where we ask the question - "Is my physical model (my equations) really describing reality."

Verification is tedious but fairly straightforward. Validation is harder, and can be really costly. Often validation requires one to do some experimental work - set up a few test cases that can be accessible both to experiment and to the computer modelling - and see how close the two are.

A neat way of doing verification is to work out analytic solutions to the mathematical equations. By 'analytic' I mean exact solutions - using pen and paper. That's often really hard in general - if you could do it you wouldn't need to do a computer model of it - but often even when you can't you can still work out certain properties that the solutions must have - e.g. what do you get when you set a particular parameter to zero, or to infinity, or what do you get when particular parameters are identical?

I've been doing a spot of verification with a summer student this morning, on a computer model we are putting together describing the response of neurons to Transcranial Magnetic Stimulation. The equations are complicated, but one thing we know is that if we set certain parameters to be identical, certain outputs from the model should be identical. More specifically, we get four graphs out - and all four should be identical. So when we had three that were the same, and the fourth that wasn't, we knew that something was up with the code.

Of course, finding  the fault  is another thing entirely. Wilson's law of verification states (from bitter experience) that the time taken to locate a fault is inversely proportional to the size of the fault. In other words, tiny little problems in the code take the longest time to discover.

In the case of this morning, we eventually tracked down the problem. It was really tiny. I'd titled one of the graphs incorrectly. Everything in the code was correct - in this regard at least - it was just that the plot that we thought was 'plot 4' was actually another plot - so it wasn't surprising it was different to the other three. The real plot 4 was hiding elsewhere - once we found it we saw that it was, in fact, the same as the others. Cue hitting head against a wall.  Code verified then. Or, I should say, verified in this regard. Verification and validation never truly stops.




| | Comments (0) | TrackBacks (0)

This morning we were treated to some talks by some of the award-winning teachers at The University of Waikato. It was a bit unfortunate that none of the talks were from the 'scientific' disciplines, but that's not because none of the winners were from scientific disciplines. We have our good share of excellent teachers in this faculty. Here are a few things stood out for me.

1. Kirstine Moffat's unquenchable use of theatre.  Granted, she lectures in English Literature, which makes putting on period costume and illustrating a point with a conversation between sock puppets less radical than in some subjects, but getting otherwise unenthusiastic students to pay attention has to be a good thing. I think if I pulled out a couple of sock puppets in an engineering lecture the room would empty faster than in a response to a fire alarm. So it would need to be a bit different, but I'm sure there's room for some creative thinking.

2. Gemma Piercy (Labour Studies and Social Policy) pulled out this quote from one of her students

The mark you get for an assignment is more valuable to you than having the knowledge about the assignment topic itself."

I think a good many students will agree with that. The comment says a lot. First of all, it says that the student is after a degree, as in the final certificate. Whether or not he or she actually has any understanding of the topic is a secondary issue; what matters is the bit of paper, because it's that bit of paper that gets them a job. Next it hints that there is something deeply wrong with the assignment. An assignment should link with a learning outcome - doing well on an assignment should be synonymous with learning. In my experience, if something is going wrong with your teaching, the first thing to look at are the assessments. And it also suggests that there is a failing to engage the students with the teaching and learning process. "Why are we learning this?" is a common question from a skeptical student. If the outcome at the end can't be envisaged, then the motivation to learn evaporates.  Gemma's done a wonderful job over the last couple of years of getting it right.

3. Then there's Juliet Chevalier-Watts (Law). With her talk, what I got out was to have the courage to try different things. Some may not work first time, some may lead to cries of derision from one's colleagues (and the students for that matter), but "if you do what you've always done, you get what you've always got." And that doesn't help anyone to move forward.

As I write this, I'm also contemplating a meeting that I have in a few minutes to discuss the nuts and bolts of a particular third-year engineering paper that I'm teaching next semester. Dynamics and mechanisms is a deeply tedious topic (I think so) - and one with a few really hard bits in it. Last year I was a little bit radical with it (e.g. the test you could talk in - also here) - this year I think I need to go a bit further. Time to start making that sock puppet.

| | Comments (0) | TrackBacks (0)