Wagner research group

Our meetings

In our group, we have a couple different meetings. Here’s a quick guide to how you should be thinking about them.

One-on-one meetings

On the Box folder Weekly meetings with lucas there is a folder Data Repository. Either there will be a folder with your name on it or make one.

In this folder, make another folder with the date of the meeting. In this folder, there should be:

  • A PDF file with :

    • A reminder of what the final graphs we want to achieve are. Show how far we are along in producing those graphs. This should make it clear why you did what you did over the past week.
    • What you did. Explain procedures in detail. What wave function exactly, how you optimized it, etc.
    • A plot showing the results.
    • References relevant to your work. Comparisons of your results to previous ones.
    • What you think the best thing to do next is, to get us to the final graphs. We may also discuss whether those are the right final graphs.

  • Data and plotting scripts used to generate the results. Data should be either:

    • ``Tidy’’ format (CSV with each row an observation and columns for all important data)
    • HDF5 format with well-defined keys. (I prefer CSV)

  • Input files/scripts that you use to submit your jobs, in particular if you are having trouble doing something.

Example meeting slides

Group meetings

The purpose of a group meeting talk is to present something that is relatively well thought out. Typically there are a few main options:

  • Present your understanding of the current literature on the subject.
  • [Present a research update.](Giving talks)
  • Practice a talk.

Hivemind meetings (currently we don’t do these)

These meetings are an opportunity to use the combined mental power of the group to help solve a problem you have. As a participant, you can also learn a bit about problem-solving techniques, and potentially learn something that will help you in your research. Usually, you will choose one of the following objectives. They are roughly in order of new project -> completed project, so which one you’ll choose depends on where you are within the project.

  1. Check your understanding of the current literature on a subject. Identify and discuss open questions.
  2. Does the design of a calculation make sense?
  3. Does the design of a package make sense?
  4. Resolve a bug or a problem you are having with accomplishing something technical.
  5. Present your logic for a paper or a talk.

For all these, it will be important that you provide supporting data. For 1. that should be the papers on which you are basing your understanding. For 2-5 there should be code and data made available.

Stand-up meetings

In these, everyone gives a 5-minute update on what they’ve been up to in the past week. Generally you should focus on roughly one question, which is answered by one plot. If you want to report on two projects, do one for each.

For each project, you should address the following questions. These should be brief. You don’t need to start entirely from first principles, but you need to be able to explain the logical thread of what you are doing. In other words, we don’t need to hear the history of the project, but we do need to understand the full context of what you have been doing for the week.

Here’s an example: Example meeting slides

Note a few things about the above (obviously they are not perfect):

  1. They first set up the problem to be solved in a clear way. There is a definition of success (in this case removing the spikes in DMC)

  2. There is a clear logical progression. It is explained what a particular calculation is testing and gives some prediction beforehand about what different outcomes will mean. This is how you improve your efficiency and avoid doing work that doesn’t mean anything.

  3. There is a conclusion that addresses the problem in 1. In this case, we started with the spikes, but then reduced that problem to just large variance (and high energy) during the optimization. That meant that our definition of success changed. This is normal, but should be documented. It is checked several ways that the change in objective is actually relevant, including some simple theory.

(semi-rant) One of the ways I most see in people getting stuck in their research is that they try to keep the entire logic of their problem in their head. It’s rare the person who can do that, and even if they can, writing it down will make it much much clearer to you. So make sure to document your logic, including writing out any mathematical manipulations/statements. Spend time on thinking carefully by writing.