Burke Blogs

Most of this information is old, but some of it is timeless. Links may also go out Lots of the information on this page is being converted to blog form. Check out a new student's account of their trials and tribulations at Dear Diary (Burke Student Meets World). If you're a current or former member, email the web manager to get access to Burke Blog Plus.

Info for Group Members

All new group members should follow the links below and read the information carefully.

Chores

Every group member has a "chore" that Kieron assigns you when you join the group (like group manager, librarian, web master, computer whiz, etc.). The description of each chore and other group management stuff is here (written by Peter Elliott, mostly still relevant but a little outdated).

Meetings

Kieron has individual meetings with every group member, ideally once a week. After each meeting you should make a plain text file that includes a summary of what has been discussed. This way Kieron can keep track of everyone's projects. The file should be emailed to Kieron with the subject "INDMEET YY/MM/DD". Please review last week's summary before the next meeting, so you can remind Kieron what you were supposed to accomplish (and explain why you've failed to do so...).

Backups

Back up your work. If you do not know how to do sequential backups, you need to learn. For example, there is a whole bunch of Burke group website stuff missing because nobody backed it up since 2011.

Notebooks

Three times a year you should write up your progress in the form of a scientific paper. Specific rules for these write up assignments used to exsist in written form, but were removed from the website prior to Ryan taking over the website. If you've already written a paper during the previous months you can hand that in. Kieron will try to give comments on your writing soon after you hand it in.

Projects

When you are working on a paper (or your write-up assignment) you should follow some rules. However these have been lost. More specific instructions for writing a paper have also been lost. Kieron's tips on paper writing can not be found, but did exist at some time.

Email etiquette

If you send an email to Kieron make sure the subject of the email is descriptive. So if the subject of the email changes in an email conversation, don't just reply but change the subject as well. This makes it easier to find emails at a later point in time. Any attachments should also be put into the relevant directory in the pbe group account and the full path given in the email.

Tips on paper writing
  1. Leave introduction and conclusion till end.
  2. Choose sections: e.g. Theory, Illustration, Methods, Results, Appendice, etc.
  3. Choose paragraphs, noting headings(i.e. make the first sentence of a paragraph tell what is included in the paragraph)
  4. Decide which pictures, which tables need to be included. Make them with caption, axes labels, etc.(i.e. complete)
  5. Introduce in a general way. This is not about the introduction section, but about every thing new in the article.
  6. Choose which symbols and equations are to be included.
  7. Define all symbols and introduce them in a logical order.
  8. Omit needless symbols(or never put them in!)

Ten Steps to Graduation

(Importance decrease from top to bottom)
10. Independence This is the criterion of graduation in Kieron's group. All people in group must have independence. You should be able to do everything by yourself. And of utmost importance, you should think independently and point out what you think Kieron did wrong.
9. Breadth and depth Do both. Look around for many things(not too close), and find out what people want to calculate; in some very specific cases, you should go very deep.
8. Logical thinking This one is the hardest. There are always logical inconsistencies in your projects, and you have to think about that at some point.
7. Networking It's important for computational & theoretical people to know people at your level and talk about stuff.
6. Verbal Be able to converse your idea on seminars. Learn to ask (dumb?) questions in front of a lot of people. (You can always phrase the question as a clarification, then follow it with your real question.)
5. Reading skills
4. Writing Figure out the logic and report it in your writing. Refer to Kieron's tips on paper writing.
3. Reliablity "Do as I say, but not do as I do,"Kieron said. Kieron can't always remember what he told you on your individual meetings or group meetings or somewhere else, so you are responsible for keeping track of all tasks he told you to do, and for reminding Kieron of them and actually carrying them out. If you can't do or don't have time for something, you should let Kieron know, not letting it hang in the air.
2. Prioritizing Learn to prioritize your own time. Kieron's example: you have two tasks on your hand: an easy one and a hard one. You can do the easy one in a week, but for the hard one you need to rewrite your codes and debug them which need several weeks. You choose to do the hard one, but when you go to your individual meeting with your results of the hard problem, you may find out that is not exactly what Kieron wanted you to do, or the situation is changed that this work is not important any more.
1. Problem solving Ability of solving all kinds of chemical, physical, and mathematical problems. You should have already developed this ability in your undergraduate study. Learn and improve. It's not necessary for everyone to achieve all, but you should learn and improve. And in the end, you should be able to put all your stuff together and generate some good output, or the money will stop.

How to Work on Projects

The rules that follow are needed within the BURG, to allow a maximum number of folks to interact efficiently on any given project. So no deviations can be tolerated.

Project management
  1.  Normally, a project will have 2 or 3 people working on it.  The most junior person (hereafter referred to as "the kid") spends the most time, and will be the first author on the paper that comes out.  The successful completion of a project should be a paper or two, and a thesis chapter, written by the kid.
  2. Often a project will grow as time goes on; the kid should try to fight this.
  3. On a first project, a graduate student can expect to spend at least one year.
  4. The kid has responsibility for keeping the project moving, focussed, and organized.

Project initation
At the very start, its vital to be organized in a way that Kieron can find relevant stuff quickly:
  1. In pbe@dft:proj, create a subdirectory with a mnemonic for the project, consisting of no more than 4 letters, such as doub (for double excitations), osc (for oscillator strengths), mem (for memory), etc.
  2. Create several subdirectories, as needed, for storing stuff as its created:
    1. binder - contains contents of binder with paper copies of notes
    2. drafts - contains all old drafts, eg k5_22.tex, h6_31.tex, etc.
    3. enotes - all enotes from the project, any eformat.
    4. enotes/figdata - contains all data used for figures in paper in ASCII format
      5. plus any specialized files (eg gnuplot scripts)
    5. lit - contains relevant pdf's while project is building, and
      6. file of bibitems; later pdf's merged into lib and bibitems will be merged into refers.txt
    6. preprint - contains compressed format for website, both ps and pdf
      7. - labelled AGB02.ps,...
    7. sub - contains submitted version of paper, including cover letter.
    8. sub/resub - for resubmitted version
    9. sub/erratum - for erratum

Early stages: Literature
As the project begins, its very important to develop a library of papers that form the basis for the project, as well as the motivation and the connection to the rest of the world.
  1. In pbe@dft:paper/lib, create another subdirectory with the mnemonic, put all e-papers as pdf's relevant to the project, even duplicating existing ones in the main lib/papers directory; later this gets moved over to the proj directory
  2. At the same time, create refs.loc, a local file of bibitems in the same style as refers.txt, listing all relevant papers.

Early stages: Keeping notes
  1. Very careful notes should be kept as the project develops.  A good way to think  about this is to imagine you are run over by a bus, and another graduate student will need to pick up where you left off.  How much time will be wasted?  Also, 50 years from now, Kieron had better be able to reconstruct everything you did, or he'll come looking for you.  There is no statute of limitations on this.
  2. The kid needs to archive everything as it gets done.  About 1/4 of all time spent on a project should be devoted to archiving.  If this is done carefully as the project develops, it will save lots of time when the paper is being written.
  3. The kid creates an archive enotes, putting all electronic notes, including graphs, etc, that she wants others to see, and keeping a contents file with a list of entries.
  4. Alternatively, the kid makes a hardcopy and puts in a binder available on her shelf of all these items, especially those that are hard to store electronically; enotes have the advantage of producing instant thesis chapters.
  5. For very general useful results, often either fundamentals from books or interesting worked simple models, the basic equations need to be added to our general notes, in proj/gen.

Middle stages: Writing a paper
  1. When Kieron (hereafter referred to as "the boss") says its time, create pbe@dft:proj/osc/drafts, with your first pathetic attempt at communicating with the outside world.
  2. All versions of the paper should be labelled both by the date and the author, eg f5.02.01.tex.  Every version should be turned into a ps and an email with the precise location sent to the boss.
  3. All papers are written in revtex.  All symbols must conform with the dft.tex macro definitions.  If new macros seem warranted, create a local macros.tex file.
  4. Within the paper, all equations should be labelled, with a useful acronym.   It should normally be texed with the eqlabels turned on.  Eg. \label{Seqn}.  All figures should be similarly labelled, but with an f: prefix, eg. \label{f:KSpot}, tables with t:, etc.
  5. All citations must be put in refers.tex according to our notation, and then cited that way in the paper.  Usually \cite will be defined simply to write the citation directly in the paper, eg \cite[HK64] makes [HK64] appear in the text.
  6. Understand that it often takes at least a year to get a paper finally finished.
  7. Omit needless words!
  8. Avoid superscripts like e^{i k x}, when \exp(i k x) will fit on the line.
  9. Use two column output everywhere to save paper.
  10. Always put integration variables right next to integral signs, to avoid confusion.

Late stages: Finishing a paper
  1. When a paper is almost ready for submission, it must be defended in a group meeting talk.  One other group member, not working on the paper, is designated as the critic.   When the critic's comments have been addressed, then it can be sent in.  The most important part of this process is usually NOT the scientific content itself, but the presentation, i.e., what has the critic not understood, and why.
  2. When ready, both a sub and a preprint subdirectory must be created, containing all materials used to generate them, eg original tex file, ps of figures, etc.
  3. When the paper is submitted, it must also be put on the  xxx server, especially if its going to a chemical journal.
  4. The paper should be added to refers.txt.
  5. Preprints, both electronic and paper, must be mailed out at that time, and it should go on the group publications website,using the usual notation.   The kid must suggest at least 12 names of folks to send it to.
  6. The notes must be turned into a permanent archive at that time, to be slightly modified upon acceptance of paper.  This just means working through all items in the notesdirectory, and removing useless duplicates, and tidying the kept ones, which must include all data tables used in figures,etc.
  7. Eventually, the work will be accepted, and the website and refers.txt must be updated, possibly changing the acronym, eg. FMB10.  At that time, the name of the notes subdirectory should also be changed.