resources | lavin & hopper, 1992 [research interview]
Anne Lavin & Mary Hopper, Passages from Personal Interview, October 2, 1992
Passage 1
Lavin: You have to be careful to teach students that when numerically modeling nature, they have to understand the limitations of the model in order to know if what they're getting from the model makes sense. It's very easy to forget that. The computer has a discrete numerical way of attacking a problem. If you attack a problem with a numerical method in areas like aerodynamics or math, it isn't always going to work because there are limitations to any given theory. How well the computer models reality depends on the quality of the model, and how well the model adapted to the fact that you are doing a numerical calculation over something that is continuous in reality. Students often forget that fact. For example, in one of the TODOR modules, a bonus question on one of the problem sets asks about the outputs of the program. The module lets students calculate the lift and drag on a multi-element airfoil system by a couple of different methods. The task is to get answers for the same given shape by
different methods and check to see which one to pay attention to in different situations from an engineer's perspective. The way one theory works, the drag you get on the airfoil is supposed to be zero because it is an idealized calculation. There is no drag in this type of theory. Of course this is not true in reality, but that is one of the limitations of the theory itself. The program does present a very small number in the drag box on the screen because of round off error. The question asks which of the two methods is better, according to the value for drag that appears. One theory tended to give positive incorrect errors, and the other tended to give negative incorrect errors. None of the students gave the right answer, which was that the one with the smallest drag value was the best. Most of the students said the theory that gave positive values was better because the negative values were impossible, because that would mean there was thrust in the air.
Passage 2
Lavin: The evaluation process was informal. A lot of our feeling about how things went was very anecdotal. Students would come up after class and say "this really made a lot of sense," or "I didn't understand why the module did something." There is no better way to find bugs then releasing it on a class of 80 juniors. We did get bug reports. We had an option on the modules to send e-mail to the administrator if there was a problem. There would be 15 e-mail messages saying, "This didn't work."
Passage 3
Lavin: All the modules have the same user interface because I said to make all of the modules look the same. The reason for a common interface was so that once the users had seen it the first time, they would go into a module and know to click in a certain place to make a certain thing happen. This was important because the modules were intended to be used in different places in the curriculum. The modules would probably be used as demonstrations in a freshman course, and then they would be used for homework assignments and design projects by the junior and senior level.
Passage 4
Lavin: When the project started, the world was still using X-Windows System version 10. Athena didn't consist of networked workstations. It was a bunch of time sharing machines with a few X terminals in a couple of the clusters. TODOR was written in a third party toolkit called BLOX. It's not a very big product. It's from a local company called Ruble Software. It was a development environment that let you define what the flow of the program would be through a series of text files. There was a menu table and a state table. They were all flat ASCII text that you would compile. You would use the tables to tell BLOX what FORTRAN routines went with a given button in the menus. It was the only thing that existed at the time, and it was invaluable. Basically, we're one of the only projects that still has software running the way it was developed in 1985. We were saved from having to deal with the changes in the X-Windows System. When we switched from X-Windows System Version 10 to X-Windows System
Version 11, the device drivers changed, so all of our codes just needed to be recompiled. We didn't realize that this was going to be one of the advantages of using this software.
Passage 5
Lavin: When I demonstrate TODOR, people expect it to be complete. They expect to know a topic when they are done running a module, although the modules were designed to be used as part of our curriculum. They are generally a tool for doing a particular calculation task, or some piece of a theory. To most people who are not aerodynamisists, they are completely incomprehensible taken all by themselves. They are also slanted to the way the topics are taught here, because they were to be used in this curriculum. Some of the theories are different from the way they're described in the book, and some of them are from the individual faculty members. They are completely tailored.
Passage 6
Lavin: Things would often get done right before the module was going to be used as a problem set . We would wake up and go, "Oh, this doesn't quite do what I intended, so we better fix it." The programmer would probably work a 20 hour week instead of a 10 hour week to get something finished. I also spent a lot of late evenings working on modules before they were used.
Passage 7
Lavin: We were protected by the fact that we had an Athena staff member on our team. Steve was our technical expert half of his time, and he worked for Athena the other half of his time. Some of the other projects didn't have as much of an applications programmer. Steve was also an excellent FORTRAN programmer. That made a big difference in terms of support. When something was coming down the road, Steve would know. BLOX would get updated, and we would recompile everything. Steve acted as our ears at Athena by keeping an eye on what was going on in Athena. He could buffer our projects from whatever happened with the system release and things like that. It was very important.
Passage 8
Lavin: I shared an office during most of the project. During the day, I also had many interruptions. It was my job to deal with the students and help them with problems. They would drop by a couple of times a day during the semester. If I had to sit down and do some coding or write some documentation, it was often very difficult to do during the day. If I've got to sit down and put my blinders on to do something, I need some time to get into it. Once I'm there, then I'm going to do it until it is done. Sometimes I would come in on weekends and spend a whole afternoon working. We also wouldn't realize how hard it would be to do a particular task, and so we would underestimate the time it would take. I would think I could get a module description done in 2 hours, and ten hours later I would have had to dig through 8 books to figure out why a theory said something. Or I would think, "I got it done in a week last time." I would forget that I got it done in a week because I stayed awake the whole time.
It just doesn't sink in that it was a really horrible week!
Passage 9
Lavin: Ours was the largest of the Athena funded projects with 12 faculty and a dozen students every year at a time. I think having a person in my position to keep track of things was very important. A lot of what I did was keep track of where the students were. We would have large group meetings once a week, and I would organize them to make sure everyone came. The students all attended regularly, and I was always there. Sometimes the faculty members came. Earll Murman would come more often than the others. He was in charge of the whole thing, and he wanted to keep an eye on what was going on. After the first year, we had one of the students present the work they were doing each week. The students would demonstrate their code that was working. I usually knew what they were doing because they would see me a couple times a week to talk about what was happening. Presenting in the meeting gave them a concrete goal to work towards. Some of it was motivation, and some of it was so that everybody else
could see interesting ways of doing things that people had come up with.
Passage 10
Lavin: In a lot of cases, I acted as a sort of expert TA for the class that were using the modules, and then I would come to class sometimes and present the module in lecture and say here's this and so the faculty member would be there and I would sort of demonstrate it, he would talk through it , or something, or sometimes, near the end of the project, the faculty member would just not come to lecture and say Anne, go and talk about this module.
Passage 11
Lavin: I was the student's direct supervisor. We had about 12 students work with us every year. During the term they worked 10 to 15 hours a week. There are no classes during the month of January, so they would sometimes work 40 hours a week. They would also often work 40 hours a week over the summer. We used a fairly rigorous interviewing process, because we wanted to make sure that they had decent programming skills and did all right in their introductory aerodynamics classes. They might not know the exact material that they were writing the program for, but they would have the background to be able to understand it. For them it was extremely valuable, and many of them got a lot out of it. They were very creative and would come up with very interesting solutions for ways of presenting things. We approached it as a learning process for the students. They weren't professional programmers, and they were learning aerodynamics as they were programming it. The students didn't have much in the way of
numerical techniques, and so it took a long time to get the code written. Sometimes bugs were introduced because the students weren't that experienced. But at least they knew aerodynamics. A lot of them were in the curriculum that they were writing the software for at the time. Consider the flip side of the coin. Suppose we tried to find professional programmers who were also aero/astro experts. Where do you find them? If you treat it as the learning experience that it was for the students, then that by itself was valuable. For example, one of our best students was finishing up the module he was working on, and he came to me and said, "we just did this topic in lecture, and I think we can write a really good module about it." So he wrote the module in about two months. We did have startling things like that happen.
© Mary E. Hopper [MEHopper] |
MEHopper@TheWorld.com
[posted 01/01/01 | revised 02/02/02]