Lab Guide

LI Research Group

UW-Madison Department of Mechanical Engineering

Last updated 07/18/2024

Group Values

  • We should all create a positive workplace for each other and support each other in our professional and personal goals.
  • Excellence is independent of background. Having a diverse community is essential for generating and sharing new ideas—whether in teaching, research, or outside of academics, and whether that diversity is concerning gender identity, sex, race, ethnicity, orientation, economic status, family status, religion, cultural background, or any other aspect of personal identity. It is important that all members of the community recognize the inherent importance of diversity, equity, and inclusion in addition to the benefits to research and community wellbeing they provide.
  • Everybody has implicit biases that can manifest themselves as unintentionally harmful beliefs or actions. We need to acknowledge these, actively work to correct them, and be willing to admit when we have done or said something wrong. As a first step towards recognizing how these biases affect your actions, there are a number of implicit bias tests you can take online (https://implicit.harvard.edu/implicit/takeatest.html).
  • The University of Wisconsin-Madison Inclusion in Science & Engineering Leadership Institute (WISELI) has prepared a “Breaking the Bias Habit®” workshop (https://wiseli.wisc.edu/workshops/bbh-inclusive-campus/) that contains information and resources, some specific to UW-Madison, that can help those of us who are not from underrepresented groups (including myself) be more active and effective allies. I would strongly encourage everyone to attend this workshop or anything similar.

 

Resolving Conflict

  • Any incident involving discrimination, harassment, or bias (including gender-based discrimination) should be reported to the Office of Compliance (https://compliance.wisc.edu/eo-complaint/). Contacting the office does not mean that you have to pursue formal action. If you would prefer completely confidential support for cases of gender/sex harassment, you can contact UW-Madison’s Violence Prevention team (https://www.uhs.wisc.edu/prevention/violence-prevention/).
  • If you are uncomfortable with the statements or behavior of another member of the group, I hope you will also be comfortable approaching me to discuss it privately regardless of whether you are taking advantage of other communication channels. I am a “mandatory reporter”, which means I need to inform the Office of Compliance if you tell me of an incident of gender/sex discrimination, harassment, or bias. You will not be obligated to meet with the Office of Compliance or pursue formal action after I inform them.
  • For any situation that directly involves me, you can reach out to the ME Graduate Chair, Department Chair, or the UW-Madison Graduate School (https://grad.wisc.edu/). If you would like to talk to a completely confidential resource, I recommend the UW-Madison Ombuds Office (https://ombuds.wisc.edu/). There are also a number of other formal and informal campus resources, like the UW Mental Health Support (https://www.uhs.wisc.edu/mental-health/).
  • UW-Madison’s Student Affairs is a terrific resource for undergraduate and graduate students (https://students.wisc.edu/) to promote well-being.

 

Group Overview

  • We develop new computational and experimental approaches to accelerate R&D in polymer science and engineering. We focus on addressing methodological challenges that will eventually enable autonomous discovery: closed-loop platforms combining software and hardware to drive the discovery of physical matter, processes, and models through automated hypothesis generation, validation, and refinement.
  • Our research covers the full spectrum between methods/algorithm development and applications. We also have a spectrum of work from computational to experimental, leaning heavily computational. Each of you will be on a different part of this spectrum that may evolve over time depending on your interests and project needs.
  • There are a number of domains we will work in: molecular simulations, machine learning, polymer physics and chemistry, materials, etc. Don’t hesitate to expose the group to new domains and suggest new research directions and collaborations. I’m interested in developing generalized methods that are relevant to many applications.
  • I am a proponent of open science. This means that we submit our manuscripts as preprints to arxiv or chemrxiv, we open source our code on GitHub or GitLab, and we try to make our tools easy and accessible for others (e.g., through public websites, detailed installation instructions, recorded tutorials, thorough documentation).
  • My current plan for the steady-state size of the group is ~10 (5-7 graduate students, 3-5 postdocs). This number will evolve in time, and has already increased a bit based on interest, funding, and collaboration opportunities. Senior members of the group are expected to take an active role in onboarding new members. New postdocs will similarly be expected to have an interest in mentorship, both of graduate and undergraduate students.
  • I will strive to be as open as possible about the “operations” of the group. You’re welcome to ask me about hiring plans, current projects, the financial situation of the group, etc. I will be upfront about these at the beginning of each academic year with a “State of the Group” presentation (remind me if I forget!).

 

Communication

  • At least for now, I check email more often than anything else and prefer it for most one-on-one conversations, including scheduling meetings and sharing documents back and forth during revisions.
  • However, Teams is nice because it provides a semi-permanent record of scientific conversations and makes it easy for others to participate and for new members to read and search. Unless you’re not comfortable talking about research updates/progress/questions in a Teams channel that is public to the rest of the group, I would recommend we do that. Feel free to “eavesdrop” on any of these channels and contribute your thoughts. Research is more fun with more people involved! Don’t be afraid to ask for (and offer) help.
  • Don’t ever feel that you’re wasting my time or bothering me. You can let me know if I’m too slow to respond and it’s urgent (e.g., an impending deadline); the fastest way to reach me in that case is by email, not Teams. I will do the same for you: if there is something with a specific deadline, I will let you know in my message.
  • We should all try to be as responsive to each other as possible. While I often send messages outside of normal hours, I won’t expect you to be working when I’m working; you don’t need to respond to non-urgent emails in the evenings or on weekends.

 

One-on-one Meetings

  • I’d like to have at least weekly one-on-one meetings for each single-advisor group member and at least once every two weeks for every co-advised group member. These are scheduled for 30 minutes but we can always increase or decrease the duration/frequency as needed. They can always be rescheduled or canceled, but it’s good to have something on the calendar. I’m always happy to allocate more time for our meeting or switch to a different schedule.
  • What we discuss at each meeting will vary over time. Most of the time, we’ll talk about recent research progress (new results, planned experiments, unexpected obstacles, etc.); for these cases, it’s helpful to prepare a handful of slides to guide our conversation. Other meetings might focus on planning, drafting, or revising manuscripts or fellowship applications. Others might focus on career development opportunities and long-term planning for your future career. We can also take this time to talk about your experience in the group/department more broadly, align expectations, and provide two-way feedback to each other. We will be able to use that time most efficiently if you have thought about what you hope to get out of it in advance and come with an agenda of sorts.

 

Group Meetings

  • Group meetings will take place weekly and will be scheduled for one and a half hours. If we don’t need the full meeting time, we won’t use it. Currently, we should try to have all of the formal discussion wrap up in an hour since lunches follow immediately thereafter.
  • One person will give a semi-formal presentation on either (a) their research progress since their last group meeting presentation, (b) a particular research topic of interest to the group, providing an overview of the field and summary of relevant literature, or (c) a practice talk for an upcoming thesis proposal, conference, etc. We will also try to use this time to invite postdoctoral candidates to give a seminar to the group if we cannot find an alternate time during the week.
    • These presentations should be planned for around 35-45 minutes to leave ample time for discussion. Everyone should strive to be an active participant in these discussions and feel comfortable interjecting with questions during the talk.
    • You should never feel like you’re spending an inordinate amount of time making slides for the sake of making slides, but don’t underestimate how helpful these presentations can be to yourself and others.
    • Your presentation on your own research will help you reflect on what you have been working on and how it fits into the overall narrative of your project. Remind us of the context for your work, why it is important, who has worked on it before, what your approach is, how it is different, how you’ve progressed, and what the next steps you have in mind are. The last point is especially important: when giving a group meeting talk, you have a captive audience for >10 person-hours and should take advantage of that to get the most value out of everyone’s experiences and perspectives. Your presentation is the best opportunity to ask for direct feedback on your approach, particularly if you’re encountering any challenges or seeing poor results.
    • Your presentation on a research topic is an excellent way to force yourself to read the literature, bring other group members up to speed, and might eventually turn into an introduction for a manuscript or serve as the seed for a review article. These meetings will be our “journal club”. Each literature talk should summarize at least 3 primary research articles. For each paper, make sure you clearly define the overarching question in the paper, the methods used, the results, and interpretation. Be honest about your assessment of the paper. Because we work on a diverse set of topics and applications, it might be tricky to choose papers that seem relevant to all members of the group. That is okay; focus on papers that are most helpful for you to advance your own research, but draw connections to the broader research themes of the group, e.g., by suggesting ways that an approach could generalize to other members’ projects. It’s helpful to post the papers you plan to cover in Teams prior to the meeting, although you shouldn’t expect people to read these papers in advance. You can always ask me to review a proposed topic.
    • You’re encouraged to form smaller informal journal club discussions, e.g., for a couple months we had a journal club discussion about enhanced sampling techniques.
  • The purpose of these meetings is not only to have the presenter educate the rest of the group on their topics, but to have the presenter seek guidance and feedback. When others are presenting, be critical (but always polite). Ask probing questions and challenge missing baselines, assumptions, and model choices. We need to be able to have these conversations with each other without feeling adversarial. This will strengthen the science that we do and help prepare the presenter for comments during conference presentations or peer review.
  • At the start of the group meeting, the speaker from the previous week will have the opportunity to present a short presentation (no more than 5 minutes) about anything they’d like: this can be a useful software package they’ve found, an interesting coding construct they’ve read or written, a recipe or restaurant they tried, or really anything else.
  • At the beginning of each semester, we’ll all select an appropriate time that works for everyone’s course schedules and other commitments (some time between 9 am and 5 pm CST during weekdays). We’ll also assign each week to a member of the group, taking turns as equitably as possible. One of our group roles is to maintain the group meeting schedule.
  • You’re encouraged to still have these group meetings even if I have a conflict or am traveling. These meetings are about the free exchange of ideas for everyone’s benefit and an opportunity to solicit research suggestions and constructive feedback, not a performance for me.
  • We also hold biweekly “subgroup” meetings for particular subtopics and collaborative projects in the group. This does increase the number of meetings you’ll be expected to go to, but I think it’s important to promote technical discussions and more frequent, informal interactions between us all. In these subgroup meetings, our focus will vary. Some might involve informal research updates in a roundtable-style discussion, where each person might present 1-3 slides of that week’s results (or questions) and lead a brief, informal discussion. Others might be more goal-oriented, and focus on discussing progress towards a specific collaborative manuscript. Occasionally, we will have ones that are more open-ended and focused on brainstorming new directions and opportunities for the group.
  • Slides from group meetings should be placed in the Research Drive (private to group members only at this point — sorry!): \\research.drive.wisc.edu\yli2562. Any notebooks/scripts from coding demos should be placed on GitHub.

 

Wellness, Work Hours, and Expectations

  • While we should strive to do impactful, ambitious research, we shouldn’t do so at the expense of our well-being and happiness.
  • Academia offers you a lot of flexibility. It’s important to keep a healthy work-life balance and use that flexibility to your advantage. More time spent working does not translate into increased productivity.
  • There is a lot of work in academia that can be done remotely or at home. Reading papers, catching up on email, preparing slides, and writing papers, proposals, or dissertations. Since a lot of our work is computational, most aspects of our work could be done remotely.
  • I hope most of you will be able to keep relatively normal working hours in the office during most weekdays, arriving between 9-10 am and leaving 5-6 pm; I would like 10-5 to be a time of maximal overlap when most people are present. I’m usually in the office from 8:30 to 5:30 or so. It’s nice to be in the office at the same time as your colleagues, both socially and so that you can quickly ask each other questions throughout the day. However, I realize that everyone’s work style and family obligations are different and you should communicate to me what works best for you. These quick questions can also be asked over Teams.
  • You aren’t expected to work evenings or weekends if we aren’t running up against immovable deadlines and if you’re managing your time well during the week.
  • Over the course of any project, there will be slow periods and there will be fast periods. If you’re at a point in your project where things are going well and you are highly motivated to push forward and make progress–do so! If you’re in a slower period and you’re feeling idle, unmotivated, or overwhelmed, take a break, go home/outside, and try to come back refreshed. I want you to feel comfortable communicating with me and your colleagues during these times so we can figure out how best to move forward.
  • There are many opportunities at UW-Madison for extracurricular activities and involvement in student groups or affinity groups. These can enrich your experience and you are encouraged to pursue them for your professional development and other intrinsic benefits, but we should talk about it first if you believe that your involvement would significantly hinder research progress.
  • There are a number of resources at UW-Madison for helping manage stress and navigate questions of work-life balance. For postdocs and research scientists, the UW-Madison HR Center for WorkLife and WellBeing (https://hr.wisc.edu/equity-inclusion-and-employee-well-being/well-being/individual/) is a good go-to. For graduate students, GradSupport (https://grad.wisc.edu/current-students/) contains several useful resources. The student health insurance program also provides very good mental health coverage; around 20% of students do take advantage of counseling through UW Health or in-network therapists.
  • Students and employees should work with McBurney Disability Resource Center (https://mcburney.wisc.edu/) and HR (https://employeedisabilities.wisc.edu/), respectively, to understand eligibility and options for disability accommodations.
  • Personal health is more important than work, so just focus on resting up and recovering when the two are at odds. Sick days are not vacation days.

 

Holidays and Vacation

  • You should take all institute holidays and all of the vacation time allowed by your position 100% guilt free.
  • Many trainees, especially graduate students, take additional time, often in the form of 3- or 4-day weekends throughout the year.
    • Postdocs need to report vacation days through MyUW. Talk to me or HR if you have trouble finding out where.
    • Graduate students subject to the Graduate Assistantship Policies and Procedures (i.e., anyone on a research assistantship, https://hr.wisc.edu/policies/gapp/) will need to request vacation days in advance (~4 weeks) and follow the rules established by the Graduate School and HR.
  • Please let me know about planned vacations when you book them if they are longer in duration (i.e., more than 3 days or so) and add them to the group calendar of planned absences.
  • I highly support tacking on personal vacation days to the ends of conferences if your schedule allows since your flight costs will already be covered. Unless there is a significant price difference, you’re welcome to book your flights to arrive/depart a couple days early/late (keep screenshots of flight prices to include in your Concur report for reimbursement). Personal expenses and hotel costs for extra days are not reimbursable; look at the travel guidelines in the ME intranet for more information.

 

Defining Research Projects

  • I try not to subscribe to a top-down approach where I define rigid research projects that you then execute. We should work together to identify meaningful and worthwhile projects that are suited to your interests and current/desired skills. Of course, I am here to provide as much guidance as needed, particularly toward the beginning of your research career. As you progress, I hope to provide you with more and more intellectual freedom to define your own research directions. I enjoy learning new fields and working on new problems too!
  • Scoping out new research projects can be very challenging. In crowded fields, you will need to navigate questions of novelty without sacrificing potential impact on real applications. Balancing risk, impact, and timelines is hard. There are some interesting articles on problem selection philosophy, including one from Michael Fischbach (https://www.cell.com/cell/fulltext/S0092-8674(24)00304-0).
  • I and others fall victim to the sunk cost fallacy too often; if we can design projects with clear go/no-go decisions (e.g., establish proofs of concept that will derisk an idea), we should abide by the results of those experiments.
  • Good research projects will have a combination of long-term goals and short-term goals. Shorter-term goals should be achievable on the timescale of weeks or months, while long-term goals may take multiple semesters. It’s also good for each project to have a very long-term objective on the 5-20 year time frame. Think of high-level phrases like “if only we could do <capability>, then <societal benefit>”. This is a good thought exercise for new PhD students scoping out thesis topics.
  • All projects should have a clear path to publication when they are started. This isn’t to say we should be chasing papers, but it’s important to know the motivation, background, and significance of our work if we are successful.
  • Collaborative projects, both within and outside of the group, are highly encouraged. Make sure you know what your colleagues and friends are working on, and consider areas of overlapping interest and opportunities for side projects. It’s wonderful when new project ideas come out of spontaneous conversations in the group offices. Or, if you see an ongoing project where you would like to contribute, you should also feel encouraged and empowered to do so.
  • Sometimes, our choice of research topics will be constrained by the grants we have secured and/or the grant opportunities we are eligible to apply for (especially for postdocs). Certain grants will have more specific deliverables that will guide what we do.
  • It can be helpful to keep an eye out for fellowships and grant opportunities that will offer us the flexibility we need to do the research we are most interested in (more on that later).

 

Documenting Work

  • It can be hard to keep a thorough, up-to-date record of your research work. This is doubly true for computational work, where it isn’t natural to record what you’ve been doing in a lab notebook. However, it is essential that we keep careful notes of our work for the sake of publications, patent filings, reproducibility, and later reference by future members of the group once you depart. You’re welcome to use whatever format you find most convenient: a written journal, an electronic word document (e.g., using Notion, OneNote), etc. I have a preference for electronic documents so that we can archive them and back them up in Research Drive or elsewhere before you leave the group.
  • See https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4565690/ for a very short guide.
  • Keep backups of everything. UW-Madison has a generous Box budget. I personally do all of my work either in GitHub repositories that I manually sync or in Box folders that automatically sync. You should actively maintain private GitHub repositories for all of your projects involving code. When dealing with large datasets, maintain copies across multiple servers when possible. We can always purchase external hard drives for the group or use cloud cold storage solutions.
  • I recommend following a strict naming convention for all presentations (at conferences, for group meetings, etc.) and all documents (meeting notes, manuscript drafts, etc.) of “YYYY MM DD <Name>”. When I am quickly iterating on a draft close to a submission deadline, I will include the time of day as well: “YYYY MM DD HH mm <Name>”.

 

Coding Practices

  • Software Carpentry workshops can help introduce you to some basic coding practices: working with a Unix shell, using Git, and basic Python commands (https://software-carpentry.org/lessons/). There is also a nice overview by the NSF MolSSI group on scripting for scientific computing (https://education.molssi.org/python_scripting_cms/aio/index.html).
  • Familiarity with a standard command line editor such as Vim, Emacs, or Nano makes editing and working on remote clusters easier. An MIT IAP class (https://missing.csail.mit.edu) offers some great tips for getting started with these editors and other helpful tools.
  • I anticipate most of our code will be in Python. You should familiarize yourself with PEP 8 guidelines (https://realpython.com/python-pep8/) and use tools like Pylint, Google’s yapf, or Sublime Text’s AutoPEP8 to enforce good style. It can also be helpful to use optional type hints (https://docs.python.org/3/library/typing.html) so that others can more easily understand your code. Google has a comprehensive style guide for Python code here: http://google.github.io/styleguide/pyguide.html
  • While working in Jupyter notebooks is a great way to analyze experiments and provide tutorials of code, rigorous testing and reproducible research is more easily conducted with a well-organized and documented codebase (e.g. https://github.com/drivendata/cookiecutter-data-science, https://github.com/rociomer/dl-chem-101).
  • Using private repositories to store and update continuous work is a great way to keep a project backed up. Pro accounts can be accessed on Gitlab with a UW-Madison netid (https://kb.wisc.edu/shared-tools/page.php?id=57963).
  • When you are ready to publish and open source your code, you should triple check that the repository does not contain any proprietary information (private data, passwords, etc., which should never be pushed to a repo in the first place) before making the repository public. It is also common to create a new clean repository and push your finalized code all at once. We will create a fork of your public repository in our group Github repository.
  • For reproducibility, you should always use a dependency manager like Conda (https://docs.conda.io/projects/conda/en/latest/user-guide/getting-started.html) or, for more complex dependencies beyond Python packages, set up a Docker container (https://docs.docker.com/get-started/overview/).
  • Best practices in software development can change, so we should all inform each other of useful resources, helpful packages, and tools. Some code-tips repositories (https://github.com/coleygroup/code-tips) will help serve as a running list of this information.
  • People have put together a set of resources showing various Pytorch implementations of common Chemistry/ML deep learning tasks that can be found here. This is a good resource for structuring projects.
  • For a good (and fairly comprehensive) introduction to deep learning, you might find the d2l.ai resources valuable. In particular, their preliminaries and appendix of tools for deep learning.
  • If you’re not sure what your development workflow should be, or how to use certain tools like Github, please just ask the group! We all had to learn this for the first time in our lives at some point, so there is no shame in asking. If you think “there must be a better way to do this”, I promise there probably is.

 

Manuscript Writing

  • Publishing in academic journals and conferences is one of the primary ways that we communicate our research with the broader community. We should never see publishing as a numbers game, but we should be aware that the quality of our manuscripts is a major way in which we are evaluated as scientists.
  • Deciding authorship order and inclusion is not always straightforward. More often than not, it will be clear who is leading the project. In those cases, I will work with the lead author to discuss the contributions of other members of the group and propose an author list for everyone involved to review. We should have conversations about authorship as early as possible–before starting a project–to avoid misaligned expectations when it comes time to write a first draft.
  • The quality of a manuscript and whether the right audience reads it is more important than the sheer number of papers we publish or the impact factors of the journals we publish in. However, we can’t neglect the fact that these factors are often used by hiring, fellowship, and grant committees.
  • Before starting to work on a manuscript (or even a project, if it is expected to be short-term), you should prepare a draft outline for us to review together. (“You” is either the sole first author, or one of the co-first authors who has agreed to write the first draft.) The longer the contribution is expected to be, the earlier we should have that conversation (e.g., a review article should always begin with a detailed scope and outline).
  • A good manuscript outline will contain the following elements:
    • Abstract: ~4-8 sentence summary that concisely describes the narrative of the entire paper. You might find the annotated Nature summary paragraph example a useful place to start, although this is longer than most abstracts for chemistry or materials venues.
    • Introduction: paragraph-level outline (i.e., list of paragraphs and what each will include). What is the 10-20 year problem being addressed? What is the more specific question this paper addresses? What has been done in the past? Why is this different/better? The final paragraph should always contain an enumerated list of this paper’s contributions. There should be 2-4 contributions contained in each paper. It’s okay for these to be thematically related; it’s hard to include more than one truly independent point per paper. Also include a sketch for the “Figure 1”, which is often a conceptual schematic.
    • Results: list of the key figure and table elements, which collectively summarize the most important experiments. How will results be depicted? Think about this early on–there are few things less interesting than a long manuscript full of quantitative results tables.
    • Discussion: any placeholder discussion sections of interesting analyses/conclusions that we already know can be included. I am particularly fond of having explicit “limitations” sections.
    • SI: any placeholder SI sections that define the total set of experiments to be performed for the paper.
  • After we work on an outline together, I would like you to write the first draft. We will likely go through many iterations together; don’t worry about getting it 100% polished before showing me a draft, but do try to make sure there aren’t distracting English errors or placeholders. As we get closer to finalizing the content of a manuscript, my comments will shift from high-level organizational changes to nitpicking grammar and word choice. When you share a draft with me, you can specify what kind of comments you’re looking for.
  • I would like us to use Overleaf (an online collaborative Latex editor) for a collaborative manuscript unless a target journal explicitly forbids Latex. It might take some time to get used to writing in Latex, but the ease of formatting figures, tables, references, and cross-referencing these in the text makes it worth it–especially for graduate students who plan to reuse parts of the text in their thesis.
    • If the article is destined for a conference, there are conference-specific templates to use. Otherwise, regardless of where we ultimately submit, it is a reasonable choice to start with the ACS article template.
    • When writing, make sure you use cross-references in Latex and do not hardcode figure, table, or reference numbers.
    • When revising a manuscript, do not create a new project for a new version. You can back-up prior versions of the text by copying the contents to a new file and continue to revise main.tex. To highlight changes (e.g., as needed for a response to reviewers), you can use a latexmkrc file and call latexdiff directly within Overleaf so that the compiled PDF highlights changes.
  • Figures should look clean and professional, using consistent font families (sans serif like Arial) and sizes (8-10 pt). I very strongly recommend using Adobe Illustrator for making figures. Postdocs and graduate students should have a free license through UW-Madison. Chemical structures should always be drawn in ChemDraw, preferably using the ACS style or a modification thereof. Graphs should be prepared programmatically using tools like Plotly (if they benefit from being interactive; the plotly_white template looks nice), seaborn, matplotlib, MATLAB, or similar programs. I strongly prefer that you don’t make plots in Excel or Prism because they aren’t generated programmatically and are harder to reproduce. See https://serialmentor.com/dataviz/ for a nice introduction to data visualization and figure preparation.
    • Even draft figures should look somewhat professional and, at a minimum, have clearly-labeled axes. Figures that are not labeled make it hard to understand what is being shown or interpret the data and can be incredibly distracting; this is true also for group meetings, subgroup meetings, and our one-on-one meetings. For example, scatterplots where points heavily overlap but scatter density is not shown, or very large heatmaps where the resolution of the screen is not sufficient to actually show all of the points.
    • When assembling multipanel figures in Python with Matplotlib, figures should be exported at the figure size intended in publication or poster to avoid awkward resizing in Illustrator afterwards. If individual panels are produced separately, axis sizes should be consistent across panels (https://stackoverflow.com/questions/44970010/axes-class-set-explicitly-size-width-height-of-axes-in-given-units)
  • While chemistry-focused journals do not have strict deadlines, some conferences and workshops do and we should all be conscious of those dates and deadlines. We’ll all be working a little bit harder in the weeks leading up to a major conference deadline if we are preparing a submission. Other journals may have deadlines for special issues or collections that we have been invited to contribute to.
  • UW-Madison offers a number of additional resources, like The Writing Center (https://writing.wisc.edu/), to help you refine your written and oral communication. You should take full advantage of these resources, particularly if there are aspects of your writing for which one-on-one coaching by someone other than myself would help.
  • As a group, we will often be invited to submit articles to special collections in journals, contribute review articles or perspectives, etc.; based on the topic of the invitation, I will do my best to distribute these opportunities evenly among members, likely giving some preference to more senior members of the group or those who have had (or will have) fewer opportunities. If you find that I am not fairly dividing opportunities, please tell me as bluntly as possible (or ask a colleague to do so anonymously) so we can work together to improve the situation.
  • Please do not ever submit work for publication (abstracts, posters, papers) without making sure I’ve had a chance to look it over.
  • When planning for deadlines, do not forget that most sponsors (non-federal, non-fellowship) require a 30 day review period to make sure that no confidential information is being included. If we have work co-authored with collaborators outside the group–especially from industry–we need to budget at least this long. This is true even for talk abstracts, so plan ahead.

 

Grants

  • Writing proposals and securing funding for the group is one of my primary responsibilities, but it is also good practice for you to develop your research and communication skills. I hope that with few exceptions, graduate students and especially postdocs will help craft grant proposals for the lab (as long as it doesn’t significantly detract from the time you need to spend on your research). This includes brainstorming, writing text, making figures, and attending meetings with potential collaborators.
  • Tell me if you have a particularly active interest in grant writing, e.g., to prepare for an academic career. I should probably already know this if we have reviewed your Individual Development Plan together. There may be stretches of times where I am writing fewer grants than average, but I will do my best to include you in the process if you have expressed your interest.
  • When articulating research ideas for a proposal, keep in mind the Heilmeier Catechism (https://www.darpa.mil/work-with-us/heilmeier-catechism). These questions are useful to consider when articulating any research proposal, not just for DARPA.

 

Literature

  • It’s your responsibility (well, both of ours, but at least yours) to stay up to stay on top of the state of the field for your research project. It’s always good to begin a project with a thorough understanding of what has been done before so we don’t end up accidentally reinventing the wheel (or worse, working all the way to a manuscript that we realize does not represent a novel contribution). As the number of distinct research topics in the group grows, I will have to rely more and more on you to help me stay up to date.
  • We have a #papers channel in Teams where you should post anything and everything that looks interesting and broadly relevant to the group. If it’s only of interest to you or a small subset of the group, still consider posting it to one of the research-related channels; this helps me know what papers I should be reading to keep up with your subtopic. If possible, read it before you post so you can provide a few bullet points summarizing the main results. If anyone thinks it’s worth a deep dive, please suggest or volunteer to present it in an upcoming group meeting.
  • I highly recommend setting up Google Scholar alerts with as many keywords as you can think of. I get most of my papers through Google Scholar alerts and Twitter. You can also set up other literature alerts (see https://blogs.extension.wisc.edu/library/resources-and-services/get-alerts/).
  • It can also be helpful to occasionally skim the table of contents in major journals related to our fields (and even “glam” journals like Nature and Science). Workshops at machine learning conferences also provide a rich source of interesting papers and ideas periodically throughout the year. This lets us keep tabs on what the most active research topics are and what kinds of studies are most valued by that community.
  • You should make sure you have a good reference manager. I personally use Zotero and its Chrome extension that lets me quickly download and categorize papers I have open. You should save every paper that has even the slightest chance of being useful in the future (e.g., referring back to, citing in a paper, sharing with a colleague). You can copy Zotero references as BibTex to paste into .bib Latex files.

 

Fellowships and Awards

  • Keep an eye out for fellowships that you’re eligible to apply for. We can work together to help prepare a competitive application for you. There are several national fellowships that should be on your radar like the NSF GRFP, DOE CSGF, plus many internal UW-Madison fellowships from the graduate school (e.g., see https://grad.wisc.edu/funding/fellowships/). Pay attention to deadlines and special requirements (e.g., securing a departmental nomination).
  • Applying for fellowships will not only help your own career, but help with the lab budget. I am willing to spend a lot of time working with you to craft your proposals and statements. Group members are also encouraged to share their application materials (successful or otherwise) regardless of whether they were successful.
  • You should also be on the lookout for internal and external awards. If you find one that’s relevant to your situation, you should feel comfortable asking myself or a colleague to nominate you. Don’t feel bad for seeking external recognition!
  • Try to give me 2 weeks’ notice to prepare a recommendation letter if I don’t already have a recent one on file. It’s helpful if you also send me your CV, any materials related to the application, and anything you would like me to highlight in my letter.

 

Conferences

  • Attending conferences is an essential part of your professional development.
  • If there is a conference you would like to present your work at, please talk to me as early as possible. I expect that national meetings of the American Chemical Society (ACS), American Physical Society (APS), and Materials Research Society (MRS) will be popular in our group. There are also several more focused Gordon conferences throughout the year and many meetings in the UK and Europe related to cheminformatics and machine learning.
  • Many conferences have specific travel awards you could be eligible for. UW-Madison also has several travel grants (such as The Graduate School’s Student Research Grants Competition (SRGC), among others).
  • There are plenty of conferences in and around the Chicago area. These are terrific opportunities because there will be no or few transportation/lodging costs. Online symposia are also very convenient for this reason, even though the experience is not the same as it is in person.
  • Graduate students should think about attending at least one conference per year after their first year (and heavy coursework) is completed, assuming that there is enough new material to share (such as a leading author manuscript or paper). Postdocs should plan to attend 1-2 conferences during their time in the group as well. At each of these conferences (except local or low-cost conferences) you should be presenting your original research in a poster or oral format. For graduate students, aiming to submit to the ACS/APS/MRS national meetings and/or a NeurIPS/ICML/ICLR workshop during your second or third year is a good goal.
  • If you are scheduled to give a presentation or poster at an upcoming conference, we should set aside time to go over what you plan to present. For oral presentations, we can use the group meeting 1 or 2 weeks prior for you to practice. I would appreciate seeing versions of posters before they are printed (the easiest place to print is UW-Madison library); how you communicate your work is a reflection of not just you, but the whole group.

 

Graduate Student-Specific Information

  • Since I was a graduate student in MechE, I’m familiar with the timing and requirements of the graduate programs in our department. However, I am less familiar with other programs. You should let me know when different milestones are coming up for you.
  • Courses
    • Graduate school is a time for learning. You are welcome to sign up for whichever courses you wish (incl. the Mechanical Engineering PhD’s minor requirement) and ideally, these will help advance your research in addition to being intellectually fulfilling. If you are interested in taking courses beyond what is required for your program, we should make sure that the increased workload will not interfere with your research progress.
  • TAing
    • Most of you will be required to serve as a TA for at least one semester or two during your PhD study. We can talk about the timing when you need to submit your course preferences.
    • I generally encourage students to TA for courses where the instructor is not their primary research advisor. The reason is simple: you have an opportunity to get to know another person on a deeper professional level, who you might one day want to ask for a second letter of reference. It’s good for someone besides me to be able to speak to your work ethic and commitment, etc.
  • Internships
    • Internships can be a valuable way to get hands-on experience working in an industrial R&D setting and gain expertise that is harder to find in an academic setting or just within our group. These could be at technology-focused organizations like 3M, Dow, Dupont, Apple, or ANSYS, at larger mechanical or chemical companies, or at startup companies applying data science and AI techniques to drug or materials discovery.
    • The best time for this experience depends on your goals. One internship is recommended and it is better in the last year of your program to help you secure a job opportunity if you choose to work in the industry. We can talk about the timing and options for you, ideally in the fall beforehand so there is ample time to plan.
  • Thesis committees
    • You should ask for advice and approval when selecting committee members. Keep your program requirements in mind (e.g., Mechanical Engineering PhD students need at least four committee members in the ME department).
  • Thesis proposal
    • We should be discussing your thesis proposal topic several months before you need to send it to your committee. As mentioned above, we should work together to define your research topic so you have ample time to become familiar with the literature and formulate a plan.
    • I would appreciate seeing at least one draft of your proposal (written & slides) before you need to distribute or present them.
    • Please do not start working on your proposal at the last minute. You should seek feedback from your peers on both the written and oral components. Schedule a practice talk, for example, with members of the lab and people from your committee members’ labs a couple of weeks in advance.
  • Graduation time
    • The time to graduate with a PhD is 5-6 years for most programs at UW-Madison. For example, the majority of Mechanical Engineering PhD students complete their degree in 6 years (Data on Time to Degree can be found at the following Graduate School website: wisc.edu/data/degrees-awarded). It’s uncommon to significantly deviate from this in either direction, but we should start planning for your eventual dissertation and departure as early as your third year. I expect that most students in the group will leave after spending 5 academic years at UW-Madison, with some buffer depending on the progress of projects and the timing of job offers. If you might be interested in spending an extra few months in the group as a postdoc to provide time between your defense and finding a new position, please let me know.
  • Theses
    • Your thesis is unlikely to consist of one continuous, fully-cohesive project. Most theses end up being collections of different projects, each resulting in some publication or other output, that are thematically similar or build off one another.
    • We can begin a conversation about the “story” of your thesis several months before you begin writing it. We should make sure there is time to go through at least one revision several weeks before it is due to your committee.

 

Undergraduate Student-Specific Information

  • As an undergraduate researcher, you will be working closely with a graduate student or postdoc. The two of you should be meeting at least weekly (in person), even if you have frequent communication through other means (e.g., Teams) between meetings. I will join these meetings as needed, since I am also invested in your success but might not have enough time to commit to a weekly frequency.
  • Because your time may be divided between many commitments, especially during the academic term, it’s important that we set expectations on the number of hours you will be spending with us. It’s important to be realistic when deciding an appropriate hours-per-week to align the project with the time commitment you wish to make. I want to make sure that you’re in a position to take intellectual ownership over your project (with ample support and guidance), so we need to work together to make sure it is properly “scoped” so as to be achievable in the timespan we choose. During the academic term, roughly 10 hours per week is typical. During the summer, full time (40 hours per week) is expected.
  • You’re also encouraged to attend group and subgroup meetings! Depending on the duration of the project, I may suggest that you present a technical talk at a group meeting (e.g., in mid-August if you join us for the summer). This is a good low-pressure environment to practice giving presentations.

 

Rotation Student-Specific Information

  • While you may be coming in with more background and experience than undergraduate students, the logistics will look quite similar. That is, you should be working closely with a current member of the group for a well-defined project duration with a well-defined nominal time commitment.
  • However, rotations are a good time to explore the different research topics in the group. You are encouraged to reach out to other members of the group to discuss their projects, interests, and think about any new projects you might be interested in pitching.

 

Opportunities for Mentorship and Outreach

  • Group members are highly encouraged to organize and participate in outreach activities! Please let me know if you hear of events where the group can have a large presence.
  • UROPs are UW-Madison’s undergraduate researchers. If you are interested in mentoring an undergraduate student (as a graduate student or postdoc), please talk to me. It is common to host undergraduates for ~10 weeks over the summer full time (~40 hours per week), but there are also opportunities to mentor a UROP during the year or over IAP.
  • UW-Madison also has a relatively large MEng program, where students can elect to stay for a fifth year to take some additional coursework and spend one academic year preparing a research thesis for an accelerated master’s degree. MEng thesis topics, due to their short duration, may be more narrowly defined than other research topics. If you have an idea for an MEng project and would like the opportunity to work closely with a student during the academic year, please let me know.
  • Only hiring undergraduates who approach us about our research is one way that underrepresentation can persist. We should explicitly advertise research opportunities on UW Madison’s UROP board and through the ME/MSE program to recruit students who may not reach out about openings unsolicited.

 

Professional Development and Career Guidance

  • One of my primary goals is to make sure you are well equipped for the next stage of your career and have all of the support and connections you need. I will provide my network of connections from academia and industry to each of you. We should periodically discuss your career goals, at least once per year, to make sure you’re on the best course.
  • Postdoctoral associates or fellows may be in a better position to reflect on their accomplishments and goals. I would like all postdocs in the group to fill out the Individual Develop Plan (IDP) template from Stanford (https://postdocs.stanford.edu/current-postdocs/navigating-your-individual-development-plan-idp/your-individual-development-plan). We should dedicate at least one of our one-on-one meetings to discuss the form. If you’re not comfortable sharing answers to all of the questions, we can simply use it as an agenda for a more free-form meeting.
  • I am still looking for good templates for IDPs tailored to graduate students (the current one is in our shared Research Drive). Rutgers also has a nice template: https://rwjms.rutgers.edu/gsbs/student_affairs/documents/IDPRutgers.pdf.
  • All members of the group are highly encouraged to use the myIDP tool from AAAS (https://myidp.sciencecareers.org/). The three assessment sections and the skill goals section are good places to start. If I and other members of the group are aware of your professional and skill goals, it will make it easier for us to support you and identify opportunities to develop.

 

Tips for Reviewing Manuscripts

  • Be kind; remember what it is like to be on the other side.
  • Lead with the most significant comments; consider separating your comments into different tiers.
  • If there is a clear path to publication (e.g., a specific set of evaluations that, if present, would satisfy your concerns), it is helpful to explicitly describe this for the authors.
  • It is generally helpful to decouple your comments on technical correctness and perceived novelty or significance. The former is fixable through revisions, while the latter may be impossible to address without a change in the study’s scope. If you believe the work is too preliminary for publication or not significant enough, you may say that, but keep it as a distinct comment from whether the conclusions are supported by the data.
  • When claims are overstated, it is most appropriate to frame your comments as saying which specific claims or conclusions are not supported by the data.
  • Do a full pass through the manuscript before starting to record your comments. I find that if I do not do this, I sometimes find myself thinking about a line-by-line revision as if I am a co-author. Proposing revisions so that the paper sounds like something you would write is not your role as a reviewer.