Illinois Bio-Grid

---

DePaul Bioinformatics Group

---

IBG Tutorial (Training Guide)

This document is a proposal for student training in the technologies required to perform research as part of the IBG Workbench (Illinois Bio-Grid Workbench) which is the research project for the DePaul BioMedicalInformatics Research Laboratory. Completing these steps will significantly add to a student's skill set in the areas of biology, Unix development, programming, and grid/high performance computing.

This material is based in part upon work supported in part by the National Science Foundation under Grant No. 0353989 in the Research Experience for Undergraduates program. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation (NSF).

The training requirement is designed to take no more than 10 weeks, depending on the student's current knowledge and available time. Some students have completed the tutorial in 2 days. If it takes you more than 10 weeks to complete the tutorial, we will have to evaluate your commitment to the project. During these time you are working on the tutorial, the student is expected to attend all meetings, report on the progress of their training, and ask questions to the distribution list. If an emergency arises and you are unable to attend a meeting, send Dave a courtesy e-mail.

The program is divided into three milestones, each milestone building on the previous. Each sub milestone "task," can be completed in about 2-4 hours. None of these are designed to be difficult, but they will require reading and hands-on experimentation. It should be emphasized that the goal of this training is to build a solid foundation of knowledge and hands-on experience for using the tools and frameworks of Bio-Grid applications.

Once a student has completed the training, they will receive an IBG grid certificate. Also, the student will be eligible to work with collaborators on the bioinformatics application workbench (IBG Workbench).

Note, this tutorial is not completely cut-and-paste. There are several items that are not completely spelled out. This is done on purpose to challenge you to learn the material. If you run into problems, PLEASE do not simply quit the tutorial. Ask questions at the next bio-grid meeting or on the e-mail list.

This document has the following sections

Prerequisites

• Access to a Unix based cluster.
  • Depaul students use mnlab or the new cluster.
  • UofC students can use the CSPP cluster or the BCR cluster.
• Sign up to the Bio-Grid distribution list.
• Understand the Unix environment. (GettingStartedWithLinux)
  • Know how to use a shell and shell related commands such as piping, shell syntax, job control/mgmt, etc...
  • Also, understand basic tools and apps such as filters, man, gcc, scp, ssh, and basic file system commands).
• Understand C
  • Know how to use pointers
• Knowledge of distributed/parallel computing is useful but not necessary (e.g. critical resource, synchronized or barriers or semaphores, etc.)
• Knowledge of biology is useful but not necessary.
• Sign up for an IBG Forum account and review the Tutorial forum. Note: You'll need to know the 'magic word' to complete the forum registration so be sure to ask an admin prior to signing up.

Milestone 1: The Unix System.

It is possible to do the four tasks for this milestone in parallel.

1.1. Programming

1.1.a. Programming: Generate an SSH Keypair for use on z-login and other unix/linux systems

Before you will be able to use Z Cluster and the other unix/linix system, you will need an ssh keypair. Generating the keypair is easy, and can be done from either unix/linux or windows.

As of 10 February 2006, passphrase access to z-login has been disabled. To log in you will need to use your ssh key. If you are a new user, please generate your key using the methods below and email THE PUBLIC PORTION ONLY to Vince Mancini at vamancini@sbcglobal.net.

Z-Cluster disk usage policy: Please do not exceed 1GB of disk utilization in your home directory. Disk usage quotas are being enforced. Error messages such as "hda8: warning, user block quota exceeded" and "hda8: write failed, user block quota exceeded too long" indicate that you are using too much disk space in your home directory. If you need more working space, please make use of the '/scratch' partition, or the new and much larger '/maxtor300gb/scratch' directory, as well as the '/maxtor300gb/data' directory. Be aware that the contents of the '/scratch' and '/maxtor300gb/scratch2/' may be deleted without warning.

Unix/Linux Instructions:

From the command prompt, type the following command: ssh-keygen -t dsa -b 4096 You will be prompted to enter a passphrase for the key. Enter a passphrase. Give the default answers to the next prompt. Copy id_dsa.pub to your home directory on z-login using sftp or scp. Login to z-login and execute the following commands from the shell:

    mv id_dsa.pub .ssh; cd .ssh; cat id_dsa.pub >> authorized_keys
    rm -rf id_dsa.pub; chmod 600 authorized_keys; chmod 755 .

Windows Instructions:

Download PuTTY and open the puttygen program. In the "parameters" box, choose a DSA key and a length of 4096 bits. Click generate and follow the prompts to save your private key. Copy to the clipboard or a new text file the generated DSA key from the Puttygen text box. (Note: this box is labeled with "Public key for pasting into OpenSSH authorized_keys file.)

Add the copied public key from your new text file to the ~/.ssh directory of the linux machine you wish to access. If you copied the key to the clipboard, fire up your preferred text editor and paste it into a new file.

Type the command: cat you_public_file_key_name_here >> authorized_keys; chmod 600 authorized_keys; chmod 755 .

Note: A properly-formatted authorized_keys file should have one key per line. If your key is broken up into multiple lines (possibly by using Puttygen's key conversion) authentication will not work.

If, by chance, you change the mode of the .ssh directory in such a way that you are unable to access it, you can correct it by entering the following command from your home directory: chmod 775 .ssh

You can also use SSH Secure Shell on Windows by clicking Edit->Settings:Global Settings->User Authentication->Keys . From there you click on Generate New ... and follow the instructions. One important note after you have securely copied your public key over to z-login is to run the command: ssh-keygen -f dsa.pub -i >> ~/.ssh/authorized_keys which puts the public key into your authorized_keys file.

1.1.b. Programming: Subversion

N.B.: This step must be done after you've made your SSH keys.

Subversion is a version control system for source codes that helps the development of software in a distributed team.

Read chapter 2 and chapter 3 of the Subversion book. If you have used CVS before you might like to read these Subversion tipps. Even if you have never used CVS before, you will find there a bunch of helpful tips for Subversion.

For the following steps the output of svn help or svn help COMMAND may be helpful.

Ask for a Subversion account as described on the SubversionAccount page. For this tutorial you will work on the repository http://histone.cti.depaul.edu/tutorialsvn/. Please make sure not to use the development repository!

Checkout http://histone.cti.depaul.edu/tutorialsvn/trunk.

Go into the trunk directory of your local repository and create a directory named according to your subversion user name. Add it to your local repository and commit your changes.

In your newly created directory create a new directory newdir/ and two empty files ./newdir/file1 and ./file2. Add file2 and newdir (not ./newdir/file1!) to your repository. Use svn status to check that ./newdir/file1 is not marked for adding and commit the changes.

Checkout the http://histone.cti.depaul.edu/tutorialsvn/trunk repository into a second directory. Then make changes to file2 in both directories. Use svn status to check the status of your repositories. After that try to commit your changes. You will receive a conflict error message. Resolve the conflict and finalize your commit. Update both of your local repositories with svn update and use svn log to see what was changed in the past.

Now, delete the directory that your have created at the very beginning from the repository.

Now you knokw the basics on subversion. If you're doing this from your own Windows machine, you might want to install a Windows subversion client called Tortoise-SVN (http://tortoisesvn.tigris.org/). If so, you should try all of the above steps again using the client. There is no on-line tutorial for Tortoise-SVN, but once you install it, there should be a new item on your context menu for any file that is checked-in (right click on the file from your Windows explorer). That new item will be a "TortoiseSVN" sub-menu, which in turn will include a "help" item. This help explains the client quite well. If you will be using Eclipse as an IDE check out a tutorial on the IBM developerWorks site on how to use Subversion with Eclipse http://www-128.ibm.com/developerworks/java/library/j-subversion/index.html.

1.2. Biology: Understanding Biochemistry

Read Chapter 1 of Fundamental Concepts of Bioinformatics, by Dan Krane and Michael Raymer (see the General Bioinformatics section in the Reading List). Note that we have an educational copy of this in our private area. Also note, that this is the textbook for CSC 531 and can be found in the DePaul bookstore.

Read the short descriptions of our research areas. The descriptions are available at: http://facweb.cti.depaul.edu/bioinformatics/Default.htm#Research.

1.3. Grid/HPC: Understanding the Basics of Grids

Read the "Anatomy of the Grid" article: (see the Grid section in the Reading list).

Security is at the heart of grid computing, and grid computing heavily relies on public/private key identification and authentication. Be sure to createa a public/private key pair as described above.

If you are unfamiliar with public key authentication, take a quick glance at: http://www.ssh.com/support/documentation/online/ssh/winhelp/32/using_public-key_authentication.html The diagrams are very informative and the text can get complicated, so for now, just check out the diagrams. Also, the ssh and ssh-keygen manuals give a decent overview of the process.

Another site that may be of use is: http://cfm.gs.washington.edu/security/ssh/client-pkauth/

Finally, read globus's brief summary of grid security at http://www-unix.globus.org/toolkit/docs/4.0/security/

Milestone 2: The Cluster.

2.1 Programming

2.1.a. Programming: MPI

Create your own MPI application. Read the Introduction to MPI presentation by Rusty Lusk at: http://www.lcrc.anl.gov/jazz/Presentations/MPIIntro-Lusk-20030924.ppt This presentation is an excellent tutorial, and was created by one of the main contributors to the MPI standard. You may also want to review this tutorial for additional detail: http://www.llnl.gov/computing/tutorials/mpi/

Implement the MPI example program on page 27 of the Lusk presentation to print out the machine names of the nodes running the progam. Output should look similar to the following (these are in rank order - you might want to try doing without rank order first):

Received processor name node1.cti.depaul.edu from machine rank 1
Received processor name node2.cti.depaul.edu from machine rank 2
Received processor name node3.cti.depaul.edu from machine rank 3
Received processor name node4.cti.depaul.edu from machine rank 4
Received processor name node5.cti.depaul.edu from machine rank 5
Received processor name node6.cti.depaul.edu from machine rank 6

NOTE : The default MPI library is installed on z-cluster in the /usr/lib/mpich directory. If want to compile an MPI application with your own MPI installation (not necessary, but helpful if you plan to do lots of MPI programming!), you may want to create/update your .profile file in your home directory with the following text:

PATH=<my_MPI_Library>/ch_p4/bin:$PATH:.
LD_LIBRARY_PATH=<my_MPI_Library>/ch_p4/lib

When building your applications, don't compile with gcc or g++. Instead, you should use mpicc or mpiCC (for C or C++ respectively). Also, remember to execute it thus:

mpirun -np "number" "executable" 

If you want to override the default machine file, execute with:

mpirun -np "number" -machinefile "my_machine_file" "executable" 

After you have tried the program without ordering the output, try doing the second part of the Lusk example on slide 27 which includes ordering the output. Another great example of maniuplating the process order can be found at http://www-unix.mcs.anl.gov/mpi/tutorial/mpiexmpl/src2/io/C/main.html.

2.1.b. Programming: Building the IBG desktop

In order to do this, you need to install the following packages

• Eclipse. You could install some other Java IDE or use command line tools, but the tutorial will only cover Eclipse. In other words, you can do the tutorial with the other tools but you're on your own.
• JUnit.
• Apache Ant
• TortoiseCVS (you probably did this with Subversion earlier)
  • Subeclipse (if you're using Eclipse)
• Java 1.5

Currently (05 Aug 2006), Eclipse uses Java 1.4 by default. In order to get it to use Java 1.5, go to Window->Preferences in Eclipse. On the left pane, click Java-> Installed JREs. Make sure that the 1.5 JRE is added and checked.

Check out the IBG desktop and run the Ant file in the project. This project name is IBGDesktop and the Ant file is called build.xml.

From Eclipse, look at Help->Ant to see how to run Ant files from within Eclipse.

2.1.c. Programming: Professionalism and Test-Driven Development

Read the paper Professionalism and Test-Driven Development at http://gridweb.cti.depaul.edu/twiki/bin/view/IBG/ReadingList#Programming_MUST_READ This is critically important for everyone's development as a programmer. I expect everyone on our project to develop in the "test first" iteration as described on the first page.

2.1.d. Programming: Reading in mzxml files

Review the code in the desktop, specifically the FormatConverter class in the org.ibg.ms.io package. This will give an example for reading .mzxml files using ProteomeCommons. Write a Java program that reads spectrum that has the value of 42 for the Scan Number field (do not count spectra - there is a trick for this) and the finds the the 42nd peak inside it (there are no identifiers for that) in the mzxml file named TEST_bsa_o16_o18_p_ms_centroided.mzxml located in the data directory of the desktop.

Warning: Do NOT look into any of the code inside of ProteomeCommons. This will just be a waste of your time. Use it the same as you would use ANY third party software - as a black box. Look at its API - that's all you should need.

Also note that the documentation for the mzXML files in ProteomeCommons is not all that good (probably because they used a tool to generate the code from the XML). You can look at the documentation for mzXML to see what the fields mean. You'll find that documentation in the sashimi project in sourceforge.net.

2.2. Biology: Understanding the computational challenges

It is important to understand the role of informatics in biology research. Why are biology applications so computationally intensive? To answer this question, you need to understand the nature and quantity of data being processed by biologists, as well as the current state of the programs and algorithms they use for interpretation and classification of biological data.

Read the short paper: http://www.statoo.com/en/publications/2003_Bioinf_SSS_46.pdf

Now that you have a better understanding of computational challenges in biology, take another glance at the research areas we are interested in, keeping in mind the challenges and goals in each area: http://facweb.cti.depaul.edu/bioinformatics/Default.htm#Research

2.3. Grid/HPC: The Java CoG Kit

This section has not really been written yet. If you are interested in Grids, perhaps you will want to help write this section.

Otherwise, you should read two papers to get an idea on what we're going to do with CoG. The first is a little old, but is at: http://www.mcs.anl.gov/~gregor/papers/vonLaszewski--grid2002book.pdf The second gives an overview of OGCE and Portlets. It is at: http://www-unix.mcs.anl.gov/~laszewsk/papers/vonLaszewski-ogce.pdf

Milestone 3: Advanced cluster skills.

3.1. Programming: Using the Z management system

Write a script and submit it to the job management system on Z (Torque). Other common job management systems are Condor and PBS. You will first need to read about using Torque at http://www.clusterresources.com/products/torque/docs20/torqueadmin.shtml (you should pay special attention to Chapter 2, "Submitting and Managing Jobs."

You should request at least four machines. Make the script print out the results of the 'uname -a' command (for Solaris or Irix, use 'uname -X'), the date command, the $PATH, $LD_LIBRARY_PATH, and $SHELL environment variables, and a list of the total number of users on the machine ('who -q' command). The script can be written in any language you like (ex: bash, sh, perl, python, etc...).

You may also read about PBS scripting at http://doesciencegrid.org/public/pbs/homepage.html

Schedule your MPI example application to run 30 minutes from now on 4 machines that have more than 500MB of memory. Schedule an email reminder for when the job has started and finished. Logout and wait for the email verifying that the job has started. Once you receive the message, log in and verify the progress with the job management system (for example, in condor, use 'condor_q -analyze'. In PBS, use 'qstat -a'). Note: If your job seems to stay in the queue, you may want to contact an administrator (RobVogelbacher, DaveAngulo, DavidKendall) so that they can manually force your job if the cluster is busy.

3.2. Biology: Sequence Analysis

A major concept in bioinformatics is comparing sequences of proteins (or DNA). Various relationships between different strands can imply many things, such as functionality, and evolutionary correlation.

All of the exercises in this section will be aimed at discovering information about the following sequence:

  MALWMRLLPL LALLALWGPD PAAAFVNQHL CGSHLVEALY LVCGERGFFY TPKTRREAED
  LQVGQVELGG GPGAGSLQPL ALEGSLQKRG IVEQCCTSIC SLYQLENYCN

To find out basic composition, molecular weight, and half-life, copy and paste the sequence into the text box at: http://us.expasy.org/tools/protparam.html

Click the 'compute parameters' button and glance over the output. Don't worry about knowing what everything means, for now it is just important to understand what information is provided.

Now that we know some more about this sequence, let's try to find out what function it might serve.

In order to simplify comparisons, several sequence file formats have been defined. One of the most popular is 'FASTA' format. Check out the one page summary of FASTA format at: http://www.ncbi.nlm.nih.gov/BLAST/fasta.shtml For readability, sequences are typically broken up into sections of 10 (like our mystery sequence above).

In a text editor, Create a FASTA compliant file, using the sequence above (NOTE: you will have to make up values for the fasta description and unique identifier. Pick something that makes sense to you.):

Go to http://www.ncbi.nlm.nih.gov/BLAST, and select the 'Standard protein-protein BLAST [blastp]' link under the 'Protein BLAST' heading.

Copy your FASTA formatted sequence into the text box and click the 'BLAST' button (the default options are fine for now).

When the query finishes, click on the red bar that lists the name of the protein you just matched.

Take a minute to explore the output. This page contains quite a bit of useful information.

Every alignment has a probabilistic score, typically referred to as the Expectation Value (E-value). E-values tell you how likely it is that the similarity between your sequence and a database sequence is due to chance.

On the output page of you query, what are the 3 best E-Value's? Check out a quick explanation of E-Values at: http://www.ncbi.nlm.nih.gov/BLAST/blast_FAQs.shtml#Expect

Are these decent E-Values? In other words, "Is it probable that you have found a likely match?"

Now that you have identified the mystery sequence, find relevant articles describing its function.

With your browser, navigate to pub-med: http://www.ncbi.nlm.nih.gov/entrez Pub-med is a database of publications biology publications.

Type in the name of the sequence in the 'for' box and click the 'go' button. Scroll through the list of publications that are returned from the query and take a quick glance at one that interests you.

Remember that the function of a protein is determined by both the sequence and the structure of amino acids.

3.3. Grid/HPC: Globus

Clusters and grids need mechanisms to manage jobs. Many users will submit jobs simultaneously, and it is up to the job management server to schedule and allocate resources, monitor execution, and return results to the user.

Globus has several job management systems available. The primary job manager is the 'fork' job manager, which does exactly that: forks a job on a machine. The fork job manager requires all requests to be in a format called "RSL" (resource specification language) Take a brief glance at the syntax and some of the parameters: http://www.globus.org/toolkit/docs/2.4/gram/rsl_spec1.html

Read the summary of Globus job management started at http://www.globus.org/toolkit/docs/development/3.9.5/execution/wsgram/user/#howto and with more details at http://www-unix.globus.org/toolkit/docs/development/3.9.5/execution/wsgram/schemas/mjs_job_description.html

Read globus's 1 page summary of information services at: http://www.globus.org/toolkit/mds/

Graduate Work: Graduating to a Senior Researcher

At this point, you have covered the surface of a significant amount of material, and you should be well prepared to contribute to the Illinois Bio-Grid Application Workbench. You will get a certificate of completion, and you should select a project with Dave's help and concurrence.

Grad.1. Working on the IBG Project.

You should read any books or papers cited in the Reading list that pertains to your area of specialty.

You should especially put in some effort to add to the reading list for your particular speciality. Perhaps even make a mini-graduate-tutorial for your speciality to help new people get involved in your area.

It probably makes sense for everyone to read the Hernandez review paper Automated Protein Identification at http://gridweb.cti.depaul.edu/twiki/bin/view/IBG/ReadingList#Mass_Spectrometry_Reading

Grad.2. Publication Guidelines

At this point, you should also start preparing a poster for your selected project. We will try to publish your poster at a local conference, such as the CTI Research Symposium / Midwest Software Engineering Conference (cTIRS/MSEC http://facweb.cti.depaul.edu/ctirs).

For all publications, you should follow these guidelines:

• Do not submit any publication without Dave's final approval.
• Do not submit any publication without the approval of all the co-authors
• DO NOT SUBMIT ANY PUBLICATION WITHOUT DAVE'S FINAL APPROVAL. This is an absolute rule without any exceptions at all - even if it means missing the submission deadline.
• Dave should be a co-author on all your publications in this group (because Dave is intimately involved with all work coming out of this lab). Dave's full name is "David Sigfredo Angulo."
• You should ensure that anyone else who contributed substantially to the project are also listed as co-authors. Note: I am more concerned with giving due credit that hogging glory. I will not be pleased with people who complain about adding someone as a co-author.
• You should also put a note on Dave's contact address saying "to whom correspondance is to be addressed."
• You should proofread your document for:
  • spelling errors
  • grammatical errors
  • adherence to formatting requirements of conference
  • conferences almost always have a page limit. NEVER go over the page limit.
    Do not submit any document to Dave for approval before you have proofread your document and ensured that there are no errors. If you are not a good writer, you should have someone help you proofread it.
• As stated in the point above, you MUST use the formatting requirements of the conference. ALL conferences have these. You should look these up.
• When submitting to Dave (and the group usually) for review, please follow these guidelines:
  • Upload a version to the private wiki site for review and send an e-mail to the bio-grid list asking the whole group to review it.
  • Make a section on the wiki page for "current version" where you put a link to the uploaded file, for "current review notes" where everyone puts their comments, and for "previous versions."
  • When you upload a new version, move the sections of "current version" and "current review notes" to the previous version.
• Please help review everyone else's documents.
• You should find out if our group has received funding for any of the work on this project. If so, the grant must be properly cited.
  • This material is based in part upon work supported in part by the National Science Foundation under Grant No. 0353989 in the Research Experience for Undergraduates program. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation (NSF).
  • This work is funded in part by the National Institutes of Health through the NIH Roadmap for Medical Research , Grant R01 HG3864
• Papers and poster abstracts should have a "keywords" section. This appears just after the abstract in papers, and at the top for poster abstracts.
• Posters
  • Posters should have a title on top, authors below that, and references at the bottom or lower right.
  • Posters should try to keep the central theme as a larger graphic in the center.
    • Details should be related through radial lines from the relevant portions in the central picture.
    • You cannot always keep to this model, but you should try.
    • Posters are not read the same as a paper. People do not go from top to bottom. The eye is drawn to the middle first. Besides, you will be standing there explaining it. You will naturally point to the center.
  • If the conference does not dictate a style of the poster itself (they usually only dictate a style of the abstract)
    • Fonts should be no smaller that 22 or 24 point
      • People will read these from several feet away
    • Text fonts should be Times Roman
    • Heading fonts should be some Sans-serif font.
    • Page size should be 36 inches wide by 47.2 inches high (and can be printed on printer at Lincoln Park).
  • Both the poster itself and the abstract (submitted separately) should have citations. Don't leave these off of the poster.

* The poster printer is at the Lincoln Park campus in the SAC building, room 224. Check the lab schedule on-line at the Quantitative Reasoning Center website; note-two classes may occupy the room at a time, but you may be able to get in if only one class is underway. Send Dr. <nop>David <nop>Jabon your DePaul ID number to have your name added to the approved users list prior to trying to print.

• Papers
  • Papers should have sections on Abstract, Keywords, Introduction, Conclusion, and Future Work. You should also review relevent prior work (literature).
• EndNote (or BiBTeX) is very good for organizing a database of citations. Endnote is really good for bioinformatics, since you can download citations from PubMed, and EndNote can automatically search PubMed with multiple criteria.
• You should try to cite our publications as much as possible. Do not cite them if inappropriate, but you should try to make comments that will make the citations appropriate. You should also cite the appropriate portion of the IBG web site.
• If you get a picture from the web or any place else, you must cite the source.
• Our group is spelled "Illinois Bio-Grid"
• When you get a publication accepted, you should put a citation on our wiki publication page.
  • This should also (normally) contain a link to an uploaded electronic (PDF) version of the document
  • If you do not have a PDF writer, you can ask Dave to convert your document
• If you do not submit your document anywhere, you should submit it as a CTI techdoc. Then you can put the techdoc citation on the wiki
• MS theses should be submitted as a CTI techdoc and cited on the wiki.

Grad.3. Reviewing Papers for Publication

If you continue in research, at some point you will be asked to review papers for a publication. If you excel in Dave's lab, he might ask you in order to give you experience. Here is a good article to help you figure out what to do: http://www.people.vcu.edu/~aslee/referee.htm

Grad.4. Contributing to the Group

Finally, everyone in the group (Dave and the other students too) help you and put in a lot of time to help you learn and have a positive experience in the group. You should do likewise. Here are some things we would like for you to do to help the group and the other students:

• Update the wiki: this tutorial and the other pages are only useful if everyone helps to keep them updated. Please help update the pages if you see an error or if you see something that can be improved.
• Update the reading list wiki: this applies even more to the reading list. It is extremely difficult and yet important to get a good list of pertinent publications. If you find a publication, please check to see that it's on the list. If it isn't, please put it there along with an additional short paragraph describing its contents and giving your opinion on whether it's worth reading.
  • You should especially put in some effort to add to the reading list for your particular speciality. Perhaps even make a mini-graduate-tutorial for your speciality to help new people get involved in your area.
• Volunteer for service: groups like this have a lot of "overhead" tasks that need to be done. The computers need sysadmins. We need people to post grant calls and calls for papers. We need people to do routine software maintenance. The list goes on forever. Please help. You will get out of the group whatever you put in.
• Participate in the group: please let Dave know if you're going to drop out of the group. Please don't just disappear. Please make the group meetings a priority. If you have an emergency and cannot attend, please send Dave an e-mail so that he knows what is happening.
• Give presentations: if you find a good paper or learn something interesting, volunteer to give a talk at a regular meeting to tell the rest of the group what you've learned.
• Be a team player: we're all in this together. Don't pick petty squabbles with each other: help each other instead. Don't be niggly about having others in the group as co-authors.
• Prosyletize: (you might need to look that word up ).
  • Talk about our group with your fellow students. Help recruit new GOOD members - those you feel are really smart and can really help the group. Remember, your participation in the group is enhanced by other good members. Also, your achievements will be more renown if the group is renown. The group will be more renown when more good people enhance the work that the group does.
  • Talk about our group to others in the industry. See above point about enhancing the reputation of the group.
• Learn: the major goal of this group is to help you learn things you wouldn't have a chance any place else.
• Have fun: the major goal of this group is to have fun.
• Sing kumbaya: OK, this was just a joke to see if you're really reading.

---

-- DaveAngulo - 23 May 2007
-- LarryHelseth - 27 Sep 2006
-- DaveAngulo - 17 Sep 2006
-- DaveAngulo - 05 Aug 2006
-- DaveAngulo - 25 Apr 2006
-- DaveAngulo - 05 Mar 2006
-- DominicBattre - 18 Jan 2005
-- DaveAngulo - 2004
-- Scott Kuehn - 2004