Contents:
In order to stretch the group's money (and, incidentally, to add a nice item to your resume), graduate students should seek out and apply for fellowships. (Undergraduates should do this at the same time as when applying for graduate school; it's good preparation for the grad school application essays, but start early, because the fellowship deadlines are before the grad school deadline.) A few fellowship programs are
There are also many targeted fellowships, such as for women or underrepresented minorities; for instance, AT&T. Other fellowships require a nomination rather than an application; for instance, the IBM and possibly the Microsoft and Siebel fellowships.
Two general lists of fellowships are available at Berkeley and Cornell. This Google search will lead you to more such lists. Each fellowship has its own set of rules; you will need to follow those rules. Deadlines are generally in the mid-fall, usually a bit earlier than graduate school applications.
If you need any additional equipment, software, or books to make you productive or comfortable, do not hesitate to ask: there is money set aside for these purposes.
First, if you don't already have a CSAIL account, you need to get one; see https://inquir.csail.mit.edu/cgi-bin/welcome.cgi
After you have an account, please set it up as follows:
cd ~
find . -path './.snapshot' -prune -o -path './.ssh' -prune -o -path './private' \
-prune -o -type d -print -exec fs sa {} pag-admin rl \;
mkdir ~/research
find ~/research -type d -print -exec fs sa {} pag rl \;
Under AFS, files always have the ACL of their directory. Thus, to make
regular(non-directory) files in your home directory private, move
them to your private directory and create a symbolic link from
your home directory to them.
/afs/csail/group/pag/software/bin/pag-daikon.bashrc or
/afs/csail/group/pag/software/bin/pag-daikon.cshrc
in your startup file (.bashrc for bash). (Once you have
done so, you will get a warning message when you log in until you
check out your own copy of Daikon.)
.emacs file: (load "/afs/csail/group/pag/software/config/emacs-daikon-group")
cd ~; ln -s /afs/csail/group/pag/software/config/.cvsrc
pts adduser USERNAME pag
You should perform your work on one of these client machines (listed from fastest to slowest).
potato, mangold radish, onion
More detail on each machine is available.
We also have a group of VMware ESX servers for efficiently running VMs. Simple instructions for using them are available.You should try to work at least part of each day at CSAIL, because you are likely to make more progress when you can turn around in your chair (or walk a few steps) to ask someone a question. If you wish to work remotely, then the easiest approach is to just ssh into one of the PAG machines.
No one has exclusive rights to any machine; you may use as many machines as you need to run experiments and do your research. However, it is polite to avoid running compute-intensive jobs on a machine that someone else is currently using. For instance, you can find out which machines are not currently in use via ~mernst/bin/share/pagdo uptime or ~mernst/bin/share/myxloads.)
Please do not run a compute-intensive screen-saver, which can use up to 99% of machine time, preventing others from effectively using the CPU when you are absent. (For shared machines, you should also log out when you are not using them, such as at night or when you are away from the computer.) If you use Gnome, set your preferences to "no screensaver":
To print at CSAIL, set your PRINTER environment variable in either .cshrc or .bashrc. CSAIL printers are labeled with their names; carrot and xerox7 are the ones on G7 (xerox7 is the copier, but it serves as a printer).
All of PAG's machines have floppy drives, CD-ROM drives, and USB ports that can be used with "memory stick" devices. To use these, insert/plug in the disk/device, and then say mount /floppy (respectively /cdrom, or /mnt/usb for a USB device). The contents of the medium then appear in the file system as the directory whose name you specified to mount. When you're done, say umount /floppy, etc., before ejecting/unplugging the medium.
Note that for permissions reasons, many of the commands described in this section will only work when you are physically logged-in to the computer (not over SSH).
scallion, parsnip, and peanut have CD-RW drives that can write CD-R and CD-RW media. To use these, use the cdrecord program. For instance, to make a disk containing the contents of a directory dir, use:
mkisofs -v -r dir | cdrecord -tao -
To make a disk from an ISO image foo.iso, say:
cdrecord -tao foo.iso
If you're re-using an RW disk, add blank=fast as an option to cdrecord.
onion, radish, and horseradish have drives that can write CD-R, CD-RW, DVD-R, DVD-RW, DVD+R, and DVD+RW media, but because of limitations in the 2.4 kernel, they cannot be configured to be simultaneously compatible with all programs. At the moment, they are set up for writing data DVDs with the growisofs program. For instance, to make a DVD containing the contents of a directory dir, say:
growisofs -Z /dev/dvd -r dir
Every week, each member of the group sends a progress report to the pag@csail.mit.edu mailing list. This progress report should also include both the previous week's plan (to see whether you accomplished your goals) and the next week's plan; of course, you should also think longer-term than one week. The body of the report should say what you have accomplished, what you learned, what difficulties you encountered or overcame, your new ideas for research directions or projects, and the like.
The report need not be onerous. It can be a few paragraphs or a page, so it shouldn't take you long to write. And any time that you spend organizing your thoughts for the report will be well-spent and will more than pay itself back in better understanding and improved productivity.
Sending the report will make your work (and meetings with other team members) much more productive, because it will force you to think about your work in a manner concretely enough to write down, and it will give others an opportunity to reflect on it before the meeting proper. The report also enables others to know what you are doing. Frequently, the reports prompt other group members to respond with ideas or suggestions of their own, which can help get you unstuck or give you additional avenues to explore.
When you have a weekly meeting with Michael Ernst or others in the group, the report must be sent 24 hours in advance, to help everyone prepare. (Two hours is no an acceptable alternative: it does not let everyone -- both you and others -- mull over the ideas.) Don't delay your report because you want to wait until you have better results to report. Instead, send the report on schedule, and if you get more results in the next 24 hours, you can discuss those at the meeting.
Even if you do not have a weekly meeting scheduled for a particular week, the progress report is required that week.
Each week, each group member meets individually with Michael Ernst, or with other members of their team. (For example, some UROP researchers will meet with a graduate student or staff member weekly and with Michael Ernst slightly less frequently.) The meeting may be scheduled for half an hour to an hour, depending on need); you can also schedule additional appointments whenever you like.
You are responsible for preparing an agenda for the meeting. This doesn't have to be anything fancy, but do spend a few minutes making a list of issues (so that none are forgotten) and prioritizing them (so that none are overlooked, and you don't spend too much time on something that isn't very important). You are also responsible for keeping track of your own research to-do list.
As noted above, a progress report is required 24 hours before the meeting. (But the report is required even on weeks there is no meeting.)
The group meets on a weekly schedule. Each week, one person presents his or her recent research results, or a paper of interest, or on some other topic. (I find this format more productive than going around the room with each person saying a few words about his or her progress for the past week.) Each group member should expect to speak every couple of months, and it's fine to talk about work in progress rather than a completed project. Speaking in group meeting need not be a high-stress proposition, because people want to understand your work and to help you. However, you need to prepare carefully in order to avoid wasting everyone's time and to get the most from others' comments.
You should plan for your talk to take 30 minutes. (With questions, they usually run closer to an hour.) When it is your turn to speak, please give Michael Ernst your completed slides two full days before the meeting (or earlier!). Then, meet with him at least a day before the meeting to get comments on the slides. This will permit you (and others!) to get more out of the talk itself. Typically, there is no need to make copies of the slides for the whole audience; that is most useful for practice talks, if you want the audience to write suggestions.
Snacks are provided by the person who spoke the previous week. Sometimes people bake; other times they buy something. You can be reimbursed for any costs you incur; submit receipts to the group secretary.
After giving a talk, you should think about the suggestions and questions, and what they suggest both about your research and about the way you presented the work. (As an audience member, you can get a lot from thinking about the presentation — what was good about it and what was bad about it — and the questions — again, which were insightful and which were not?) The speaker should generally also debrief with Michael Ernst afterward, to get more comments and suggestions.
Consider attending the Program Analysis Reading Group (and suggesting papers for it to read). This is an excellent way to learn more about current research, and to learn about how to read and write technical papers. All are welcome.
You may also wish to see Michael Ernst's advice on giving a talk.
As with any request, when a user reports a problem with your software, it's quite important to give a reply right away -- even if your response gives a date on which you will address the issue. Otherwise, the users (rightfully) feel they are being ignored. It's especially important to give a quick reply when you have to ask for more information, so that when you get around to the issue, you aren't delayed. In this case, you could have just asked for a test case, so that we can reproduce the problem and ensure that it is fixed.
When you reply to a bug report sent to a mailing list, please use your mailer's reply-all feature so that others know the issue is being dealt with. Otherwise they might waste time -- and confuse users and appear unprofessional -- by duplicating your work.
The outcome of research -- whether at the UROP, M.Eng., or Ph.D. level -- should be a paper describing what was learned and disseminating that knowledge for the benefit of other researchers and practitioners. For instance, a summer's work might result in a conference or workshop paper. Please keep in mind where your results might be published and whether what you are doing contributes to the state of knowledge (either directly or indirectly).
Each week, each group member prepares a written progress report as a short email message. It only needs to be a couple paragraphs or a page long and will probably only take 15-30 minutes to compose, but it should explain what you have accomplished, what you have learned, and what you plan to do next. This is very helpful both in permitting others to understand what you have done, and also in focusing your attention on whether you have been productive and keeping you on top of your progress.
Each week, the Program Analysis Group meets to hear a more in-depth report on the current status of one group member. Each member presents during group meeting every 2-3 months. These presentations may be informal, but they should be organized in a way that permits others to both understand and critique the work. The presentation may use handouts, overhead transparencies, and/or a whiteboard. Plan the presentation for 20-30 minutes; questions are likely to draw out the meeting to one hour, but we will try to avoid meetings longer than that.
Giving work (such as thesis proposals, theses, and papers) to others to review at the last minute is very hard on those individuals, who may have other work planned for that time. Accordingly, please deliver thesis proposals before December 1 (unless you have already published a paper and so not as much review is necessary), and theses before May 1.
In the spring, we write a CSAIL research abstract for each project that some group member worked on during the previous year. If you have recently written a paper on your research, this is a simple matter of reducing it to two pages. If you have not, then you will find it useful to think about how to express your contributions and explain what you have done.
Here are a few tips regarding the research abstract:
Michael Ernst
Last updated: March 26, 2011