We have six IBM and four Macintosh computers. The department supplied these. We also have a lot of other equipment that is vital to the operation of the lab, and is possible only through the support of the NASA ADP. Without this support and additional money from a special state allocation, the facilities would not exist. They include a large HP plotter and two X-terminals for access to two IBM RISC 6000 workstations. The computers are networked, and we have a laser printer for the IBMs and a laser printer for the Macs. Table 2 provides a detailed list of our hardware, and Table 3 defines our network setup. The network is crucial for several reasons. Perhaps one of our biggest problems is controlling software. This occurs in two ways. Initially most surprising to us was that the machine would grow software! Also, the process of backing up the system was difficult. We could not guarantee that software we were given with the stipulation that it not be further distributed was safe. We also needed to free-up hard disk space. Many of the programs are huge. Because of this experience, in the 1994-95 school year we went to a network system, using one Mac and one PC as servers. We could prevent students from making illegal copies of software and we could back up the system reliably.
Most of our applications are personal computer based, and are listed in Table 4, Table 5, and Table 6. Initially we had limited workstation capability. Essentially, they were saturated by the graduate education program. In addition, the students are required to have personal computers, and are already familiar with IBM Pcs.
A series of manuals have been assembled covering 1) Aircraft Sizing and Performance, 2) Aerodynamics, 3) Stability and Control/Handling Qualities, 4) Propulsion, and 5) Structures. The effort to support codes and create adequate documentation is significant. Most old-time user's manuals intended for use by full-time users with experience are not adequate for students. Many of these manuals list the input by card number. Today's students have never seen a computer card, and frequently ask what the instructions mean! Gradually, the manuals are being converted to HTML, and will be all electronic. We have already done this with our information sources document (Mason, 1993). This approach is good because it keeps the manuals from disappearing and makes it is easy to update the manuals as students identify problems with them.
Several lessons have been learned. We found it impossible to control the software on PCs operating in an open environment. The hard disk space would evaporate as students placed their own versions of word processors and other programs the students used on their machines at home. For example, some students installed Lotus 123 because they use it at home. Hard disk space also evaporated due to working files by students, i.e., CAD drawings, and FORTRAN programs and final design reports created by the students. CAD programs presented a special problem. We kept the most current version of CADKey and AutoCAD on the design lab computers. At Virginia Tech, students purchase a computer and a software set as freshmen. This meant that as seniors, the students have a version four years behind the current release. This created problems. Although new software versions can almost always read files from previous software versions, the reverse is not true. So a problem arose when a student used the current version of an application (typically CAD) in the design lab and then tried to take his work home on a disk to work on his own computer. In some cases we had to keep multiple versions of a software package on the design lab computers (although students can upgrade their software for an amazingly small fee, few do). Another especially troublesome problem on the lab computers was the possibility that students would change the configuration files. Programs that worked one day would not work the next day. (This was a major problem for the graduate assistant.) Typically this meant that the plotter would not work. Viruses also caused continuing problems. Generally, the Macintoshes suffered less from these problems. However, software control was also a problem on the Macs, and software purchased to solve the problem seemed to work well initially, but eventually several of the hard drives locked up, and the problem went away when we removed the protection software.
Hardware reliability is also a problem. The hard use of the system (24 hours a days during the last month or two of the semester), together with a poor environment (air conditioning was finally installed in the Fall of 1994, but building renovation continually generates significant dust and other airborne particles) led to fairly frequent hardware failures. A lot of problems arise with "hand-me-down" components. Disk drives, monitors and printers required a large amount of the graduate assistant's time. These components needed to be repaired regularly. After a crash considerable time was required to reestablish the software on the various computers (note that students, even though they had been using computers for four (or five) years by the time they were seniors, invariably claimed to have lost enormous amounts of work because they had failed to backup their files!).
To solve the system configuration problems we have moved to a network solution, as detailed in Table 3Table 3. For the Macintoshes we installed another Mac in the department system administrator's area to act as a file server, and our core system is on this Mac, where we can control access, keeping the applications secure, while allowing users on the other Macs to access and run them. This has worked well, although the initial startup of an application is often slow. Perhaps our biggest surprise came when we installed our own programs. We found that many of the design codes needed to establish local scratch and output files. Initially they would try to write these files to the original, write protected area on the Mac being used as a server. Fortunately, the compiler we use for FORTRAN-based applications (Language Systems) has a special I/O command to allow us to let the users move file I/O activity to their own directories. We had a similar experience with the IBM system once we got it established. To help students use programs that were protected, we put a folder with sample input files for each program on a directory or folder on each machine. Thus the students could copy these files to their own directories to use to run the program the first time and to use as templates in developing their own input files. It turns out that this is the problem that is solved when you buy a "network" version of a program. Often, this is not possible for engineering design specific software.
We installed the Novell system for the IBM PCs. This system has only been in place since November of 1994, and we do not have long-term experience experience with it. However, It was easy to install and control, and is similar to a UNIX-based system. Groups could have access permission. It works well with the Windows and DOS environment. Again, we did have read/write problems with software that was not configured for the network.
Using a network solution in a room where the computers were all very different, typically being added at the rate of one a year and also acquiring "hand-me-down" or as the school termed it: "trickle-down" equipment produced other problems. Naturally, all the machines had different CPUs, amounts of RAM, etc. The intention was to be able to run all the programs on the server from each computer. It was difficult to do this. In some cases we couldn't. AUTOCAD only works on 3 of the 5 computers because they all don't have the hardware requirements to run the program. Upgrading some of the machines is too costly to justify. Thus, collecting a group of different computers in a network will not solve all the problems.
For design, our experience demonstrates that a workstation environment would be much more effective than the PC environment developed in the early `80s at Virginia Tech as a solution to the computer problem. Some sort of hybrid system is probably required. One problem that arises is the need to teach students UNIX when we do give them access to our X-stations for workstation use. Asking students to be proficient on Mac, IBM DOS/WINDOWS and UNIX is probably too much to expect.
Finally, each Macintosh has a complete set of newsreaders, MOSAIC/NETSCAPE, gopher, email and fetch software. Although the students now have complete access to the internet, the usage is low for design class work. Only a very small number of students take advantage of the wealth of information available on the internet. Since incoming freshmen now get all this software, I expect this to change in the future. To improve communication, newsgroups were established for each of my classes in the Spring of 1995. Starting in the Fall of 1995, each student will be required to make two posts (either questions or answers), so that they can be motivated to start using these tools.
The main lesson in the use of the computers in design is that there are continuing problems in establishing a system for student use. The instruction of students in how to use codes, how to use the computing system and repairing problems (Students always claim that they did everything right and that there is a system problem. This is wrong at least 80% of the time.) adds a huge burden to the graduate student assistant and the systems administrator as well as the design instructor. Academic administrators generally don't appreciate this aspect of the use of the computer in the education process. This is "high tech" as they think of it. For design, the computer actually increases the workload for the faculty, graduate assistant and systems administrator rather than decreasing it. This is the exact opposite of the story they are telling, where the computer can be used to increase staff productivity and reduce educational cost.
Finally, we stress the importance of following the restrictions on software copying. Codes obtained for free, typically from NASA, include restrictions on the use and further dissemination. Violation of these provisions could result in loss of access to codes in the future. Most commercial codes also have strict rules for their use. By setting a good example we try to make students aware that the long term professional consequences of not honoring software usage restrictions could be very severe.