Group guide for:
AI Laboratory for Molecular Engineering (AIME)
Chalmers University of Technology
Section for Data Science and AI, Department of Computer Science and Engineering
ailab.bio

Note that this is a living document and some sections may change. Feedback welcome!

Last updated: January 2, 2026.

Group values

Teamwork — AIME is a team! This means that we not only work together to tackle challenging and impactful research questions, but also support each other in reaching our professional and personal goals. We lift each other up and create a positive workplace environment.
Growth — Doing research involves exploring new ideas and tackling unsolved challenges. This means coming face-to-face with failure often. However, we don’t see failure as a negative thing, but rather as a positive experience from which we can grow and develop our abilities. Even if we cannot control a situation, we can control our response. We understand that if things are not going well, they will not stay that way forever, and we can work towards changing or improving things. We are not afraid to try a new approach, ask for help from a friend or colleague, or take time off to recharge when we’ve hit a wall. We practice a growth mindset.
Diversity, equity, and inclusion — Diversity, equity, and inclusion (DEI) go hand-in-hand with excellence. A diverse community is able to generate diverse and creative ideas, which are critical in research and teaching. Diversity can refer to differences with respect to gender identity, sex, race, ethnicity, orientation, economic status, family status, neurodiversity, religion, cultural background, or any other aspect of personal identity. We recognize the inherent importance of DEI and are not only respectful of each other’s differences, but also advocate for each other and make an active effort to continuously educate ourselves on the principles of DEI and find better ways in which we can be inclusive.
Open communication — We clearly and kindly communicate our ideas, thoughts, and expectations, as well as our disagreements. When prompted, we can clearly, effectively, and most importantly respectfully give feedback to other group members, whether positive or negative. However, we never critique something that a person cannot change and ensure all feedback is polite and constructive. We acknowledge that we all come from different backgrounds and have had different experiences, and that this can sometimes lead to miscommunications. We are not afraid to ask for help or clarifications when we do not understand something, and we are not afraid to share our ideas, however unusual they may sound. We are always open and willing to share our knowledge with each other.
Improving society — The goal of making the world a better place for all underlies not only the research problems we choose (e.g., molecular engineering with therapeutic applications), but also how we present and report our findings (open-access) and publish the tools we build (open-source). We do not put up unnecessary barriers to our science. We behave ethically at all times. We are keenly aware that improving the world starts with improving our immediate environment. As such, we seek to create not only a positive work environment, but also a good environment in our division, department, and university.

Group overview

In AIME, we are interested in developing methods for molecular engineering using artificial intelligence. By bridging machine learning and chemistry, we hope to develop a better understanding of how molecules interact to form complex systems, and how we can use these insights to engineer molecular systems for therapeutic applications.
We are currently focused on applying our computational tools within the drug discovery and materials design domains. In particular, we are interested in improving our understanding and the design of multi-target therapeutic modalities like PROTACs and molecular glues, which require large networks of proteins to come together and cooperate for the desired therapeutic effect to occur. We are also keenly interested in phenotype-guided molecular design. In the most recent years, we have also begun diving into materials design questions and how we can accelerate the development of promising new materials with machine learning. However, this does not mean we are not open to discussing new domains or new research directions and collaborations!
Close collaborations with leading academic and industrial groups in computational chemistry, bioinformatics, computer science, and materials science are very important to us. Furthermore, we value our collaborations with experimentalists, as working with experimentalists allows us to better understand the problems we are trying to solve, find limitations in the data we work with, and help design workflows for collecting relevant new data which may advance projects in AI-driven molecular engineering.
Our research covers the full spectrum of methods/algorithm development to applications. Where each member lies on this spectrum may evolve over time depending on each person’s interests and project needs.
We are strong advocates of open science. This means that, whenever possible, we submit our manuscripts as preprints to the arXiv, ChemRxiv, or BioRxiv, and we open source our code, models, and data on GitHub, Hugging Face, or Zenodo. We make a deliberate effort to design tools which are easy to use and accessible (e.g., through thorough documentation, detailed installation instructions, tutorials, etc) and which follow good programming and data sharing practices.
My current ideal steady state size for the group is ~10-15 (8-10 graduate students, 3-4 postdocs). This number has evolved steeply over the last few years and will continue to evolve in the future, but for now we are in a good steady state that I hope to maintain for a few years. Depending on the academic calendar, team members will include MSc students working on their 6- to 12-month thesis projects; usually we host 4-8 students during the springtime and 1-2 other students at other points in the year. As we grow, I expect that the senior members of the group will take an active role in onboarding and mentoring new members (for PhD students, this typically means around the halfway point in the PhD). Postdocs are expected to have an active interest in mentorship.
I aim to be as transparent as possible about the operations of the group. You are always welcome to ask me about hiring plans, current projects, finances, etc. I will be upfront about these things at least once each academic year with a “State of the Group” presentation.

Communication

I check my Chalmers email rocio.mercado@chalmers.se and AIME email rocio@ailab.bio daily. My email volume has grown significantly in the last few years, so regarding work matters, I generally prioritize emails from group members, department colleagues, and Chalmers students. However, I am occasionally not great at responding, particularly when travelling. If it ever seems I have missed your email, please write me again to remind me. For extremely urgent matters, please call me (phone number in my email signature).
More generally, I will do my best to return feedback promptly, but during busy periods (teaching, grant deadlines, conferences), I may be slower than usual. If you have an urgent deadline and haven’t heard from me, please follow up.
If you need me to do something (e.g., provide a signature, give feedback on a manuscript), try to make this clear in the message through the use of bold text, along with the date by which you need me to complete the task. I will do the same for you: if there is something with a specific deadline, I will let you know in my message.
If you would like to schedule a meeting with me, my calendar availability can be easily found here. I recommend all group members use either Google Calendar or Outlook to create event invitations for meetings, to make it easy for myself and others to add the event to our calendars, quickly see any potential conflicts, etc. Calendar invites can be sent to any of my emails, they are all synced in my central calendar (Google Calendar). Note that due to technical difficulties I cannot sync things with my Chalmers Outlook calendar, so please do not refer to that one for my availability.
We also have a group Google Calendar where we keep track of group events, like group meetings, seminars, workshops, and socials. I recommend you add this calendar to your list of calendars you follow; all group members are also able to modify and create events on this calendar.
For more technical conversations or back-and-forth discussions on a manuscript or research project, I recommend to use the AIME Slack as it provides a semi-permanent record of scientific conversations. We often have similar problems in our research, and Slack makes it easy for other group members to participate in a discussion and see what others think (as well as contribute your own thoughts). We can use our 1:1 channels for asynchronous updates and more private discussions, but I also strongly encourage you to use the shared team channels (e.g., #papers, #social) to share interesting papers, workshops, activities, etc. that others might also appreciate and benefit from.
I expect you to check Slack at least once daily, as this is the primary channel via which we disseminate important information to the team and via which I can communicate asynchronously.
Don’t ever feel that you’re wasting my time or bothering me when reaching out! You can let me know if I’m too slow to respond and something is urgent (e.g., an impending deadline), either in person, via email, or in a private Slack message.
While we should all strive to be as responsive to each other as possible, I definitely don’t expect you to respond to messages outside of standard working hours (M-F 9-5) nor should you expect this from other team members. Similarly, do not feel obliged to respond to emails/Slack messages outside of your typical working hours.

Resolving conflict

If you are uncomfortable with the statements or behavior of another member of the team or division, please don’t hesitate to come to me so that we may discuss it privately and identify the best way to resolve it.
For other situations, you might feel more comfortable reaching out to the DSAI Head of Unit for PhD students and postdocs, Selpi (selpi@chalmers.se).
In work related matters, the Chalmers external occupational healthcare service (arbetsmiljo.stodet@chalmers.se) may also assist you.

One-on-one meetings

I’d like to have one-on-one meetings once every week with every group member for whom I am the sole/main advisor, and once every 2-4 weeks for every co-advised group member (e.g., industry PhD and MSc students, with the understanding that you are having more frequent meetings with another supervisor). These would ideally be scheduled for 30 minutes to 1 hour, depending on your need, and we can always increase or decrease the duration/frequency as needed. They can always be rescheduled or canceled, and I will frequently need to reschedule during teaching- or conference-heavy periods, but it is good to have something on the calendar. I’m happy to allocate more or less time for our meetings as needed, but you need to make sure you communicate what your needs are. Further, if you are cancelling too many meetings we will need to discuss why this is the case and if there are any deeper underlying issues that need to be handled.
What we discuss at each 1:1 meeting will vary as you progress through your time in the group, and will have slightly different focuses for MSc students, PhD students, and postdocs. Most meetings, we’ll talk about recent research progress, challenges, and ideas (new results, planned tasks/experiments, unexpected obstacles, etc). Other meetings might focus on planning, drafting, revising manuscripts, or revising 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 more generally about your experience in the group/division/department, align expectations, and provide two-way feedback to each other.
Besides our regularly-scheduled 1:1 meetings, feel free to schedule additional meetings with me as needed. I am also happy to chat anytime that my office door is open (if it is closed, please respect that I am either in another meeting, or trying to do some work that requires deeper focus).

How to prepare for 1:1 meetings (“managing up”)

Our 1:1 time is precious and limited. To make the most of it, I expect you to come prepared. This is not optional—it’s a skill you’ll need throughout your career, often called “managing up.” Here’s what I expect:

Prepare slides. Before each meeting, prepare at least 2-3 slides:
- Slide 1: Refresher. Briefly remind me what we discussed and agreed on in our last meeting. I am often coming from meeting to meeting and cannot keep everything in my head. This also helps us check whether you completed the action items we set.
- Slide 2+: Current progress and questions. Summarize what you’ve done since our last meeting, any results you have, what you need advice on, and proposed action items for the coming week(s).
When you have results to share, present them as well-formatted plots with clearly labeled axes, and avoid using screenshots of code or unprocessed data to guide our discussions. Even if not publication-ready, taking the time to make a proper figure tells me you have thought about and analyzed your results, and that you have put thought into what type of feedback you need from me; this will make our discussions more productive. Screenshots of terminal output or raw numbers are hard to interpret and suggest you haven’t processed what you’re looking at.
Take your own notes. While I take detailed notes, you should not rely on mine as those are for my records. Bring something to write with (or type on) and note down key decisions and action items; this can also be done within the slidedeck you’ve prepared. At the end of each meeting, briefly summarize the takeaways back to me so we can confirm we’re aligned. This prevents misunderstandings and saves us both time later.
Drive the agenda. You know your project better than I do on a day-to-day basis. Come with a clear sense of what you want to get out of the meeting. If you’re stuck, say so explicitly. If you need a decision from me, frame it clearly. If you just need to brainstorm, let me know. Whatever it is you need, it helps if you communicate it clearly at the start of the meeting so I know which “hat” to wear.

Subgroup meetings

In addition to our 1:1 meetings, we organize biweekly subgroup meetings where members working on related topics meet to discuss their work in progress (WIP). Currently, the subgroups are drug discovery and design, materials design, and microscopy (the latter together with TIMED NEST collaborators).
I strongly encourage everyone to share WIP early and often with other group members (not just with me). Your colleagues can help you catch blind spots, suggest approaches you might not have considered, and help you avoid wasting weeks on a direction that may not work. They can also provide support. Don’t wait until you have polished results.
Subgroup meetings are an excellent venue for this, and a safe space in which to share your messy, early ideas and findings. Come prepared to give informal updates, ask for feedback on approaches you’re considering, and engage constructively with others’ work. Take advantage of our collective knowledge; someone else in the group may have previously encountered the exact problem you’re facing.

Group meetings

Group meetings take place weekly and are typically scheduled for 1 hour, except during holidays and summer months. We currently have joint group meetings with the AIMLeNS group on Friday afternoons.
For PhD students and postdocs, attendance at group meetings is required. Please discuss with me in advance if you ever need to miss a group meeting.
MSc students are not required to attend but you are of course welcome and encouraged to attend.
During each meeting, two group members will give a semi-formal presentation on either (a) an introduction to their research project, (b) their research progress since their last group meeting presentation, or (c) a practice talk for an upcoming presentation.
- These presentations should be planned for around 25-30 minutes, leaving some time for discussion. Everyone should strive to be an active participant in these discussions and feel comfortable interjecting with questions or suggestions during the talk.
- Presenting 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 and the research we do in the group.
- When introducing a new project, be sure to provide an overview of the field and summarize the relevant literature.
- When presenting on your research progress, make sure to remind us of the context for your work, why it is important, who has worked on it before, what the state-of-the-art is, what your approach is, why this is a better approach than what’s been done before, how you’ve progressed, any challenges you are facing, and what the next steps you planned are.
- Your group meeting presentation is the best opportunity to ask for direct feedback on your approach, particularly if you’re encountering any challenges or seeing poor/unexpected results.
The goal of these meetings is not only to educate the rest of the group on what you’re working on, but also for you to get feedback on the talk along with fresh ideas on how to move forward with your project. To get the most out of group meetings, both as a presenter and as an audience member, I expect all attendees to be active participants.
When others are presenting, you as the audience are expected to be critical but constructive. Ask probing questions and challenge any missing baselines, assumptions, and model choices (politely—do not become adversarial). This will strengthen the science that we do, as well as help prepare the presenter for comments during conference presentations or peer review.
As a presenter, be mindful that everyone has taken time out of their busy schedules to listen to you present, so put an effort into structuring your presentation well so that not only you but everyone present can get the most out of this experience.
At the end of each academic term, we’ll draft the group meeting schedule for the coming term. It is your responsibility to check the schedule as soon as it is published, and inform us ASAP + try to find a replacement if there are any conflicts with the date you are scheduled to present.
After a presentation, slides from group meetings should be placed in the group Google Drive folder (private, available to group members only). This will be helpful for returning to something a member has previously presented, as well as for me to easily borrow slides/figures for seminars and conference presentations.

Wellness, work hours, and expectations

Sweden has comparably strict work environment acts and regulations relative to other countries. PhD students, for instance, are typically employed at Chalmers and have the same rights and obligations as all employees.
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 a lot of flexibility. It’s important to keep a healthy work-life balance and use that flexibility to our advantage. More time spent working does not always translate into increased productivity.

Office presence expectations

While there is a lot of work in our field that can be done remotely or at home, I expect everyone to be in the office at least 3 days per week. This is not only my expectation, but Chalmers policy: working from home (WFH) is permitted up to 2 days per week maximum. Note that working from the library or a café counts as working from home, not as office presence—the point is to be physically available to your colleagues and vice-versa.
I would like 11 am - 2 pm to be a time of maximal overlap when most people are present in the office. This is when you’re most likely to catch colleagues for quick questions, impromptu discussions, advice, and/or fika. Nevertheless, I realize that everyone’s work style and family obligations are different, so please communicate with me (and our unit head) ASAP if you ever have a situation that requires special attention.
I tend to come into the office most days, as I prefer to take meetings in person, though I work from home every now and then. I usually arrive in the office around 8-10am and stay until 3-5pm, and then WFH a bit in the evenings as necessary.
On days you are working from home, try to indicate so in your Slack status or in the group calendar.

Workload and pacing

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, then please do so. If you’re in a slower period and you’re feeling stuck, unmotivated, or overwhelmed, take a break, either to work on something else or to have a small holiday, 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.
Personal health is more important than work. Just focus on resting up and recovering when you are sick. Sick days are not vacation days.
You aren’t expected to work evenings or weekends, especially if we aren’t running up against immovable deadlines and if you’re managing your time well during the week.

Health, sick leave, and extended absences

Your health—physical and mental—comes first. If you are unwell, please rest and recover. Do not come to the office sick.
If you anticipate needing extended sick leave (more than a few days), please inform me as soon as you are able. I understand that some situations arise suddenly (e.g., accidents), but for health issues that develop over time, early communication allows us to plan appropriately and ensure you get the support you need.
Sweden has good sick leave policies. Generally, sick leave needs to be reported in Primula, and you will need a doctor’s certificate to receive extended sick leave with pay. There is some paperwork that needs to be done depending on the duration of your sick leave, which we can discuss, together with our unit head and HR, if you are ever in a situation which requires taking it.
Note that partial sick leave is possible. If you are able to work part-time but not full-time (e.g., 50%), this can be arranged. This is common for recovery from burnout, chronic conditions, or phased returns to work.
If you are struggling with your mental health or feeling overwhelmed, please reach out—either to me, to a colleague you trust, or to Chalmers support services. You are not alone, and there are resources available to help.
For more information, see the Chalmers intranet page on sick leave.

Wellness resources

Chalmers provides opportunities for preventive wellness activities. For instance, the Chalmers Student Support page has many online resources. The Chalmers Studentkår also has a page with many useful tips and resources, as well as the Chalmers Doctoral Students Guild (support for PhD students page).
For options on disability or functional accommodations, you can find more general information here, and more software-specific information here.
Additional information on health, safety, and the workplace environment can be found on the Chalmers intranet.
There are many opportunities at Chalmers 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 (e.g., pedagogical courses, writing seminars, etc.) and other intrinsic benefits, but we should talk about it first if you believe that your involvement may affect your research progress. More information on professional development resources at Chalmers can be found on the Chalmers intranet.

Holidays and vacations

PhD students and postdocs at Chalmers have the right to vacation days, and your vacation entitlement is as follows*:
- 28 days until and including the year in which you turn 29 years old,
- 31 days from and including the year in which you turn 30 years old,
- and 35 days from and including the year in which you turn 40 years old.
Employees are entitled to 20 days of vacation during the summer months of June–August. If you prefer, you can schedule your vacation at a different time of year, but know that you are legally required to use at least 20 days of vacation per year, and you should take these 100% guilt free.
Many folks take additional time, often in the form of 3- or 4-day weekends throughout the year.

*Please consult official sources for more accurate numbers in case there are any changes; this is not a legal document and I am just putting the numbers I remember to give you an idea.

Vacation planning and notification

Please follow these guidelines for communicating planned time off:

Duration	Notice required	How to report
1 day (spontaneous)	At least 1 week in advance	Slack/email + group calendar + Primula
2-4 days	At least 2 weeks in advance	Slack/email + group calendar + Primula
1 week	At least 3 weeks in advance	Discuss with me first, then Primula + group calendar
2+ weeks	At least 1 month in advance	Discuss with me first, then Primula + group calendar

All vacation must be registered in Primula (Chalmers’ time reporting system) and can be reported in increments of half-a-day.
Additionally, please add all planned absences to the group calendar (whether holiday, WFH, or conference travel) so that colleagues know when you’ll be away.
If your planned vacation coincides with an important group event (e.g., a group meeting where you’re presenting, a deadline, AI4Science seminar, a visitor), please discuss with me before booking.
If two or more people want the same time off around a critical deadline, we may need to coordinate. Please check with colleagues working on the same project, students you supervise, examiners for courses you teach, etc. before finalizing plans.
If it is something you are interested in, I fully 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 reimbursement report). Of course, you are not reimbursed for any personal expenses (e.g., hotel, meals) during any personal vacation period, and this is something you need to indicate in Primula when submitting the reimbursement report for the accompanying conference.
For the most up-to-date information regarding holidays, please see the Chalmers intranet.

Defining research projects

My expectation is that we will work together to identify meaningful and worthwhile projects that are suited to your interests and current/desired skills. I am here to provide as much guidance as needed, particularly toward the beginning of your research career. However, as you progress, I hope to give you more and more intellectual freedom to define your own research directions.
For new students: I typically have funded projects with defined research directions, so you will not be expected to invent a project from scratch. We will work together to find a good fit between your interests, the funded project, and the group’s ongoing work. As you become more experienced, you’ll have more latitude to shape your own directions within these boundaries.
Generally speaking, projects should have a clear path to publication when they are started, whether it be as an article, blog, software package, and/or toolkit. Even if the project fails, it should be defined in a way that we learn something meaningful from that failure. You should have a meaningful motivation for your project that aligns with our group values.
I find it to be a good idea for most students to have at least two research projects: one with shorter-term goals (weeks/months) and one with longer-term goals (months/years). The long-term project should be designed such that you are able to break it down into many more manageable short-term goals.
I encourage you to work together on projects! Take advantage of each other’s complementary skill sets. Research is much more fun when done as a team.
You should have an idea of what “major problem” in the field your project is addressing. However, you don’t have to solve this “major problem” with each of your projects; making incremental steps towards helping us solve it is also progress.
As you get more comfortable and experienced with the research process, I hope to encourage you to take riskier and riskier projects (high risk, high reward). Of course, we will work together to define what this means for you.
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.
Note that you are not allowed to work on external research projects without prior approval from me; doing so may conflict with your funding obligations and employment terms, and could constitute a breach of research integrity. If you would like to continue working on a project you started prior to joining the team, or start working on an external project, please discuss it with me before accepting or commencing this work, especially if it would affect your ability to deliver on your main research project or if you would need to use group resources to do so.
Sideline activities need to be reported to me and to Chalmers (this can be done in Primula); please discuss with me if you are unsure what constitues a sideline activity.
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).

Research strategy

Good research requires not just hard work, but strategic thinking. Here are principles I want everyone in the group to internalize:

Start with simplified experiments

Before running your full pipeline on your full dataset, run simplified, controlled experiments first. For example:

Use a tiny dataset (tens or hundreds of examples, not thousands)
Verify that your model can overfit to a small set—if it can’t, something is wrong
Test individual components in isolation before combining them (often it is the process of combining components that reveals issues)
Use synthetic or controlled data where you know the ground truth

These quick experiments give you signal fast and help you catch bugs or flawed assumptions before you’ve invested weeks of not only compute time but more importantly your valuable research time.

When stuck, narrow down your scope ruthlessly

If you find yourself in a research plateau or swamp, stuck for more than 2-3 weeks without clear progress, this could be a sign that the problem you’re trying to solve is too broad or ill-defined. The solution is almost always to narrow down the problem significantly:

Reduce the scope of your experiment until you can get some result
Isolate the specific component that’s failing
Ask a simpler version of your question

I repeat this advice constantly because it’s one of the most common mistakes I see, both by junior and senior researchers alike. Don’t spend a month debugging a complex system when you could spend a day debugging a minimal version of that same system.

Write early

I recommend you start outlining or drafting a paper at the first signs of positive results. Don’t wait until you have “enough” results. Writing early:

Forces you to clarify your story and identify gaps
Helps you prioritize which experiments actually matter for the narrative
Prevents the common trap of running endless experiments without a clear endpoint
Makes the final writing process much less painful

Even a rough outline with placeholder figures can guide your research direction and help you avoid research plateaus.

Documenting work

It is important 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 Obsidian, Notion), etc. I have a preference for electronic documents so that we can archive them and back them up, and they are also searchable.
Keep backups of everything, and remember to back-up regularly! I cannot emphasize this enough. In fact, I would strongly recommend that you have an automated back-up system (e.g., automatically syncing OneDrive, iCloud, etc). Everyone I know who has ever lost important files or data was “planning on everything backing up tomorrow.” Don’t let this be you! Backing up your data is something that may take 30 minutes to set up but can save you weeks or even months of work down the line if you are ever so unlucky as to have your files lost. I personally do 99% of my work either in GitHub repositories that I manually (but constantly) sync, locally on my laptop which is automatically backed up in OneDrive and iCloud, and in Overleaf documents that automatically sync.
For projects involving code, you should actively maintain private (before publication) GitHub repositories for all of your projects. When dealing with large datasets, try to maintain copies across multiple servers when possible.
I recommend following a strict naming convention for all presentations and documents. Personally, I use “YY-MM-DD - [Filename]”; electronic files following this convention will be easy to sort in chronological order.
If you do not already use a password manager, I strongly recommend you start. LastPass, Bitwarden, and Keeper are popular choices. Cybersecurity is important, and if you feel unsure what sort of things you should be thinking about, please don’t hesitate to ask me at our 1:1s.

Shared resources

Our group has access to shared computational resources, storage, office space, equipment, and meeting rooms. Please use these responsibly and with integrity.

Compute and storage: Be mindful of shared compute resources. Don’t monopolize GPUs or run jobs that could be run on smaller machines. Clean up old experiments and datasets you no longer need regularly. If you’re unsure whether a job or set of jobs you are planning to run is too resource-intensive, ask. Use the #programming channel in Slack for this type of questions.
File permissions: All files stored on our shared compute and storage allocations must have read access enabled for other team members. This practice ensures reproducibility and continuity when projects are handed off or when colleagues need to build on your work, and also makes it easier to manage our group resources. It is not permitted to store private files in our shared resources.
Offices and meeting spaces: Keep shared spaces clean and tidy. Book meeting rooms through the calendar system and release bookings you won’t use. Be considerate of noise levels, especially in shared offices and in the hallway.

Good coding practices

AIME consists of members with a range of programming experiences. If you feel that you would like to improve your programming skills upon joining, there are some nice online resources for getting up to speed on these things (see the introductory tutorials linked in the onboarding guide).
Regardless of your background, I highly recommend the online course “The Missing Semester of Your CS Education” from MIT CSAIL.
Most of our code will be likely be written in Python. You should familiarize yourself with PEP 8 guidelines and use tools like Pylint to enforce good style. I also strongly recommend that everyone in the group use (optional) type hints in their code so that others can more easily understand what you have written. Google has a comprehensive style guide for Python code.
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. For examples on how to structure your codebase, you can have a look at the dl-chem-101 repo.
There is no single “right way” to structure your code as long as it is easy to run, and your calculations reproducible. However, try to follow accepted conventions when possible. Reading codebases for other packages is one of the best ways to see and learn good coding practices (as well as bad). You can also have a look at common cookiecutters, such as this one from MolSSI.
An excellent way of looking at how you can improve your code and the accompanying documentation is to imagine yourself looking at your codebase 6 months from now. Would you be able to reproduce what you did?
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 so that the commit history is not visible (if this is relevant for your project). You are welcome to either create the repo directly within the AIME group GitHub (recommended if maintainance of your code is planned by others continuing in the team), or in your private repository. In the latter case, we will create a fork of your public repository to the group GitHub at the time of publication.
I require you to have someone else in the group review your GitHub repo before publication. If they are not able to run your code, then it is unlikely that other folks, less familiar with your work, will be able to do so. This may take a long time depending on the size of the codebase so make sure to properly acknowledge those who help out in the review process (and, ideally, pay it forward).
For reproducibility, you should always use a dependency manager (e.g., Conda, Mamba, venv, etc). For more complex dependencies beyond Python packages, use containers (e.g., Docker).
Version your code, especially upon publication. This way you can always reference and/or return to the exact version used in specific publication.
Best practices in software development change, so we should all inform each other of useful resources, packages, and new tools. The group Slack is a good place for this (e.g., #programming channel).
If you’re not sure what your development workflow should be, or how to use certain tools like GitHub, please just ask! We all had to learn this for the first time in our lives at some point, and there is no shame in asking.

Manuscripts

Publishing in academic journals and conferences is one of the primary ways that we communicate our research with the broader community. While we should never see publishing as a numbers game, we should be aware that the quality of our publications is a major way in which we are evaluated as scientists, for better of for worse.
Typical publication venues that I anticipate will be relevant to our group’s research include (but are not limited to) conferences such as ICML, ICLR, AISTATS, CVPR, AAAI, KR, and NeurIPS, conference workshops such as AI4Mat and ML4Molecules, and journals such as JCIM, J. Cheminf., Machine Learning: Science and Technology, Nature Machine Intelligence, Digital Discovery, etc. We should also strive to publish our work concurrently on the arXiv, ChemRxiv, or BioRxiv when possible so as to maximise the accessibility and reach of our research.
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. With the sheer volume of publications coming out each day in out field (a problem only made worse by the rising capabilities of LLMs), I also feel it is important not to “litter” the literature with mediocre manuscripts or “salami slicing”, and we should do our best to avoid this practice.

Authorship

Authorship reflects intellectual contribution to a piece of work. Getting this right matters for careers, fairness, and scientific integrity. While generally it is straightforward to determine who is an author on a paper and who isn’t, here are some guidelines for when things are less straightforward:

Discuss authorship early. For any project involving two or more people, discuss possible authorship at the start of the project, not when you’re ready to submit. Involve me in these conversations. It’s much easier to set expectations early than to resolve disputes later.
Often, one person is clearly leading the work—doing the bulk of the experiments, writing the code, and drafting the paper. In these cases, that person is first author, and we’ll work together to determine appropriate ordering and inclusion for others based on their contributions.
When authorship is unclear: If co-first authorship is expected, or if it’s ambiguous whether someone’s contribution warrants authorship, this must be discussed explicitly and early. Don’t assume: communicate! Do not wait until a paper is submitted to communicate misaligned expectations; please communicate any possible issues as soon as possible.
Contributions must be scientific. I expect clear, substantive scientific contributions from anyone listed as a co-author. Providing data, running experiments, writing code, developing methodology, writing/editing the manuscript, and providing critical intellectual input all count. Administrative support or general supervision without intellectual contribution typically does not warrant authorship.
We use the CRediT taxonomy. All papers from the group should include a CRediT (Contributor Roles Taxonomy) author contribution statement. This provides transparency about who did what.
Reproducibility and handoffs: If a project is handed off to another person to complete, and the original work cannot be reproduced (or must be completely redone), the original researcher cannot expect authorship. We will not reward sloppy or undocumented work; if we need to re-do everything, then the work did not push forward scientific progress. Ensure your code runs, your data is accessible, and your methods are documented before stepping away from a project.

Manuscript preparation

Before you start writing a manuscript, you should prepare a draft outline for us to review together. A good paper outline will contain the following elements:
- Abstract: A short paragraph that concisely describes the narrative of the entire paper. You might find the article “How to construct a Nature summary paragraph” useful when preparing an abstract (I frequently reference it, both for preparing conference and publication abstracts).
- Introduction: A couple of paragraphs describing the problem being addressed, how others have tried addressing it in the past, and what you are doing differently. You should also include a few sentences here on how your new method is different/better.
- Contributions: A short section (usually bullet points) summarizing the 2-5 main take-aways from the manuscript.
- Methods: A couple of paragraphs, ideally divided into subsections, discussing the technical details of the method(s) you have developed, the data you are working with, the various experiments you ran, etc. However, do not present or discuss results in this section.
- Results: A couple paragraphs summarizing the key results of your study. Here, you should be strategic about how you present the results, particularly in the figures (a well-done figure is much more enjoyable to read than a wall of text).
- Discussion: Here, you can go a bit more into a detailed analysis of your results. You can discuss , for instance, if something was surprising/unexpected, what the advantages and limitations of your method are, etc.
- Conclusion: A short paragraph or two summarizing the narrative of the paper, with an emphasis on the outlook of the work (i.e., what do you plan to do in the future? what questions remain unanswered?).
- Code and data availability: One of the most important sections of the paper. Here, make sure to include links to your code (typically on GitHub) and any data necessary to run or reproduce your results from the paper. If the data is too large for a GitHub repo, one alternative is to upload your data to Zenodo.
- Acknowledgements: Please acknowledge our funding sources (there is usually specific guidelines for how we must do so — check with me if unclear). Also, acknowledge others who have helped you out with your project but perhaps with smaller contributions than a fellow co-author.
- Author contributions: Include a CRediT (Contributor Roles Taxonomy) author contribution statement.
- Appendix: Can contain additional data or details that an interested reader might reference, but that would be clunky or disrupt the general narrative of the paper if included in the main text.
However, note that the specific outline and required sections will depend on the venue you plan to submit to. For instance, chemistry journals don’t typically expect a separate “Contributions” section, and different journals have different required sections (and word/page limits). Most journals and conferences provide a pre-formatted LaTeX/MS Word template which you can download and use as a starting point for your manuscript.
After we work on an outline together, I would like you to prepare the initial draft. Start with the Methods and Results sections, focus on creating a draft of all the figures you will want in the paper. I strongly advise against writing the paper in a top-to-bottom fashion (that is, starting with the abstract, and ending with the appendix); this is not only the slowest way of writing a paper, but an easy way to get “stuck” in the writing process.
We will likely go through many iterations together, so don’t worry about getting it 100% polished before showing me the first draft. However, do try to make sure there aren’t significant distracting typos or formatting issues; my role as your mentor and supervisor is not to be your copy editor, so please use the appropriate tools to check your grammar, spelling, etc. As we get closer to finalizing the content of a manuscript, my comments will shift from high-level organizational changes to suggesting more specific wording changes. When you share a draft with me, you can and should specify what kind of comments or feedback you’re looking for, if you would like me to focus my feedback to a specific section you’ve rewritten, etc.
I would like us to use Overleaf for every manuscript unless a target journal explicitly forbids it. It might take some time to get used to writing in LaTeX if you are not familiar with it, but the ease of formatting figures, tables, references, and cross-referencing these in the text makes it worth it, especially for MSc and PhD students who plan to reuse parts of the text in their thesis reports.
Figures should look clean and professional, using consistent font families (sans serif) and font sizes. Make sure all plot elements are suitably labeled, and that text in a figure is legible (e.g., the axes labels, tick labels, etc.). Generally, I recommend you avoid including plot “titles” (this is a practice more common in student reports); this type of descriptive information should instead be in the figure caption.
Chemical structures should be drawn in ChemDraw, preferably using the formatting style for the specific journal/venue you are aiming for. If no formatting instructions are provided for chemical structures, use ACS style guidelines. You can get a ChemDraw license via the Chalmers software center. I recommend against using RDKit drawings for molecular structures in a publication (for less formal reports or 1:1 meeting slides, this is ok).
Graphs should be prepared programmatically using tools like seaborn, matplotlib, or similar programs (avoid using MS Excel).
When assembling multipanel figures in Python with Matplotlib, figures should be exported at the figure size intended in publication or poster.
Please do not ever submit work for publication (abstracts, posters, papers) without making sure I’ve had a chance to look it over. This applies to any archival venue: conferences, workshops, journals, and preprints. This is about quality control, ensuring I’m aware of what the group is putting out, and protecting you from preventable mistakes.
While chemistry-focused journals do not have strict deadlines, computer science conferences and workshops do and we should all be conscious of those dates and deadlines. We’ll all likely be working a little bit harder in the weeks leading up to a major conference deadline if we are preparing a submission.
When planning for deadlines, do not forget that if we have work co-authored with collaborators outside the group, then they also need to review the paper and give their consent. So please budget for this time (always give at least 2 weeks for someone to review your manuscript). This applies for any archival publication, including a poster abstract.
Here are some additional resources for scientific writing:
- For preparing a good (albeit, long) abstract: “How to construct a Nature summary paragraph”
- “How to write a contemporary scientific article”
- “Scientific writing: The art of programming brains”

Grants

Writing proposals and securing funding for the group is one of my primary tasks as PI, but it is also good practice for you to develop your research and communication skills. If you would like to be involved in grant writing while in the group, graduate students and especially postdocs are welcome help write grant proposals for the lab as long as it doesn’t significantly detract from the time you spend on your research. This includes brainstorming, writing text, making figures, and attending meetings with potential collaborators, etc.
Please tell me if you have a particularly active interest in grant writing, e.g., to prepare for an academic career.

Literature

It can be challenging to keep up with the literature in such a fast-moving field like ours. It feels like every week there is a new groundbreaking paper. We should help each other stay on top of the state of the field as best we can by sharing papers with each other and discussing them.
We have a #papers channel in the AIME Slack where you should post anything that looks interesting and broadly relevant to the group, whether it be an article, blog post, or recorded talk. If possible, read it before you post so you can provide a few bullet points summarizing the main results. Usually such a summary can help kick-off a thread discussion.
When it comes to your own research project, it’s good to begin with a thorough understanding of what has been done before so we don’t end up accidentally reinventing the wheel. This is a real risk in interdisciplinary fields like ours. As the number of distinct research projects in the group grows, I will have to rely more and more on you to help me stay up to date.
To stay on top of the literature, you can also set up RSS feeds, Google Scholar alerts, or follow relevant feeds on social networking platforms like BlueSky or LinkedIn. I also recommend signing up for newsletters or blog digests that summarize recent research highlights in a broader context. I personally recommend c&en, BioBytes, The Curious Wavefunction, Sebastian Raschka’s blog, and various others.
Make sure you set up a good reference manager. I personally use Paperpile and its Chrome extension that lets me quickly download and annotate papers I have open. Another popular choice is Zotero (open-source). It doesn’t really matter too much which system you use as long as you can reliably keep track of the interesting/relevant papers you read, meaning you can easily find specific papers later in paper-writing or when you need to find a reference for something.

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. When preparing any fellowship application, pay close attention to deadlines and special requirements (e.g., you may need to secure a departmental nomination or administrative approval).
For any of you who are funded by the WASP program, I encourage you to take advantage of the available opportunities they provide for graduate students.
Applying for fellowships will not only help your own career, but help with the group 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 regardless of whether they were successful. There is no shame in getting an application rejected; sometimes it is simply bad luck but usually we can learn from the process and improve our proposal based on the reviewer’s comments.
Always read clearly the evaluation criteria and, if possible, understand who will be evaluating your application so as to best tailor your application to the target audience. It can be helpful to put yourself in their shoes when reading through your application to see if you have included everything they would be looking for.
Keep an eye out for internal and external awards. If you find one that’s relevant to you and you would like to be nominated, please don’t hesitate to ask me or a colleague to nominate you!
Try to give me at least a couple 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 (see Recommendation Letters).

Internships

While it is quite common for graduate students in computer science programs abroad to pursue summer internships, it is not such a common practice here in Sweden. However, I believe such experiences can be invaluable, especially if you know you would like to pursue an industrial career after your PhD, or if you are undecided between academia and another career path.
Please let me know if this is something you would be interested in and we can figure out how to go about it. I can also help you reach out to people at various companies, especially if I have a connection there.
For WASP-funded graduate students, there is generous funding available for research stints abroad or international study visits. I encourage you to take advantage of these opportunities!
Note, if you are a student from abroad reading this and would like to visit my group as part of your MSc thesis, please read up on Erasmus guidelines at your university as that is the easiest way for you to do a research stay in my group. It is also possible to host students with their own funding for short-term research visits in the team.

Conferences and schools

Attending conferences can be a valuable part of your professional development, but conference travel is expensive (in both time and money) and should be purposeful.

Conference travel policy

I expect that any conference travel is tied to presenting your work, either as an oral presentation or a poster. This is an important part of research outreach and an obligation we have as researchers when receiving research funds. On the other hand, attending a conference “just to attend” is generally not a good use of group resources (or your time), especially for international travel. Our team funding generally comes from public funds, and we should use these resources with integrity. If you would like to attend a conference “just because”, I may instead suggest you self-fund and take out your personal vacation days to attend.
Before applying to any conference or workshop, discuss it with me first. Not all venues are worth the time and money. Some workshops, conferences, or schools seem relevant but, from experience, have low payoff. I can help you prioritize and identify the relevant ones.
Keep in mind that some funding sources (e.g., WASP, DDLS) require attendance at their specific summer schools, annual conferences, and workshops throughout the year, so be mindful of these deadlines.
Do not submit an abstract, paper, or poster to a conference without getting my feedback and approval first. This ensures quality control and prevents you from committing to sub-par or irrelevant venues.
Once we’ve agreed on a venue and your submission is accepted, I am happy to support your travel. See below for logistics.

Conferences of interest

I expect that international machine learning conferences like ICML, ICLR, and NeurIPS will be popular in our group. However, take advantage of local opportunities as well, such as the Gothenburg AI Alliance (GAIA) annual conference and the Nordic Conference on Computational Chemistry (at AstraZeneca), as well as European conferences such as the RDKit User Group Meeting and the German Cheminformatics Conference, to name just a few. There are also several focused Gordon conferences throughout the year which may be relevant.
Keep an eye out also for relevant conference workshops, such as the ELLIS ML4Molecules and AI4Mat workshops, as well as affinity groups like Queer in AI, Women in Machine Learning, and LatinX in AI. These are not only great opportunities to present your work but also for networking.
Local events are terrific opportunities because there will be no or few transportation/lodging costs, there are no challenges with obtaining a visa, and you can avoid being gone from home for extended periods. Online symposia are also nice for these reasons, with the added benefit that registration is often free.
For WASP-funded students and postdocs, the annual WASP Winter Conference is a great opportunity for networking and learning about cutting-edge AI research going on in Sweden. You are also expected to attend if you receive WASP funding. Similarly, DDLS-funded students are expected to attend the DDLS Annual Meeting, which is also great.

Preparing for conferences

Many conferences have specific travel awards you could be eligible for, so make sure to do some research when looking into the potential costs and apply for these far in advance.
If you are scheduled to give a presentation or poster at an upcoming conference, we can set aside time to go over what you plan to present, especially if it is your first time at a major conference. You are also encouraged to seek feedback from the team. For oral presentations, we can book a time slot for you to practice your presentation for the group; this is a good chance to get valuable feedback from group members in a low-stakes, non-threatening setting.
For poster presentations, I would like to see a draft of your poster before it is printed. However, once it is printed, you are encouraged to reuse it, especially if you have two or more back-to-back conferences or workshops.
Remember that how you communicate your work is a reflection of not just you, but the whole group, so always take it seriously and help each other out.
For a great resource on how to prepare engaging scientific talks, I highly recommend the “How to Speak” lecture from the late Patrick Winston.

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 participate.
Examples of programs which may organize recurring outreach events include, but are not limited to, the WASP Diversity and Inclusion Group and GENIE.
If mentorship is a skill you are particularly looking to build in your time at AIME, let me know. Senior PhD students and postdocs will be expected to take on some mentorship responsibilities for junior group members as time goes on. There may also be the opportunity to mentor students outside AIME.

Professional development and career guidance

One of my primary goals is to make sure you are set up to succeed the next stage of your career and that you have all of the support and connections you need. I will provide my network of connections from academia and industry to each of you. It is also in your best interest to periodically discuss your career goals with me at least once per year, that way we can make sure you’re on the best course for achieving these. Note that your goals may change during your PhD or postdoc, and that is okay!
One option and possible medium for discussing these goals is to fill out an Individual Development Plan (IDP) and to set up a meeting to discuss your professional development plans with me. This way I can best provide guidance throughout your time in the group. More details about this, and the IDP template, can be found in the onboarding guide.

Group socials and fika

The relationships we build both in and outside the lab can add value to our lives and help build a positive environment for us to thrive in. Although our research is awesome and certainly a large part of our lives, it should go without saying that there is more to life than research!
One way to foster a fun, collegial environment that we look forward to coming to every day is through regular group socials and fika. If you don’t know what fika is, you will soon learn.
For group socials, we will organize semi-regular events where we meet up outside of work about once every few months for activities like group dinner, hikes, pub quiz, etc. If you have any ideas feel free to suggest them, or even organize a social yourself, but remember to ensure that organized group socials are inclusive of all lab members who want to join. You are of course welcome to bring any guests to these events.
Don’t ever hesitate to ask anyone in the group or division to lunch. This is one of the easiest ways to meet your colleagues, and everyone is very friendly and will almost certainly say yes. There is a café, Linsen, in the EDIT building where you can get lunch at a relatively good price, but you will find that most people bring lunchboxes from home and heat them upstairs (the fika room doubles as a lunch room). There are a few good restaurants in and around campus as well.
The division also organizes an annual group retreat which is a nice way to meet our colleagues outside of AIME in a less formal setting.
Finally, there are many great student organizations around campus that regularly organize socials, and I encourage you to ask more senior group members about these and participate if you are so inclined.

Acknowledgements

This group guide was modeled after the Coley group public group guide (in 2022), available at coley.mit.edu.