Episode 32½ - Why season 4 took so long, and a few impressions

Transcript

Milosz 0:10

Welcome to Phase Space Invaders. It's your host, Miłosz Wieczór speaking. With the last panel discussion, we reached episode 32, so let me summarize briefly the eight conversations from Season 4. We had a few topics, a few themes that came up quite frequently, and I think there's still some value in trying to piece them apart. I guess it first and foremost helps myself wrap my head around all these issues that were brought up by my guests. But I thought I'll keep sharing them with you in case it gives you food for thought, as after all, many unexpected solutions and projects come from a problem being exposed to a broad enough audience and, uh, you know, someone smart and dedicated committing a lot of resources to working it out Then towards the end, I'll give you a quick update on my moving to a new position and, uh, why the podcast has been quite sluggish recently, to put it mildly. And so one thread I really liked was the question of what the absolute fundamentals of our fields are. This came up in discussions with Pratyush Tiwary, and it also came up during the panel conversation with Xuhui Huang. The idea being that we have three pillars in our field: the biological component, the physics, and the data or machine learning part. And, uh, I really feel it's increasingly hard to split your research in such a way that a pure biologist, pure physicist or pure data scientist or AI researcher can meaningfully contribute. I mean, this is obviously possible, and we've seen examples of that, but as a research problem, it has always been a very hard question for me. You know, how, how do you compartmentalize a complex project in computational biophysics so that any single person who only sees a tiny part of the big picture can meaningfully contribute to it? And of course, there are many solutions to that. One of them is to train PIs so that we can act as both, so to say, connectors and separators And, uh, we can break apart complex problem into pieces, assign those pieces to different people, and then integrate those solutions back into a working scenario, so to say. But this is extremely hard. I think very few people can do that successfully in a way that really harnesses the best knowledge of people who, you know, are specialized in biology, in physics or machine learning. And to me, this is a hallmark of really great scientists, and I really envy the people who are good at it because it's such a rare and, and useful skill. But then the other solution is to try to train students in a more holistic way, and I think we try to highlight this solution. This is also the way that has been the preferred approach for me. It's how I grew up as a scientist, you know, adding more and more components to my toolkit and more angles from which I can approach a bigger problem. But it has the obvious drawback of missing certain amount of depth because you're not always able to draw from the really rich history of physics, the latest developments in AI or, you know, the deepest biological insights coming from recent experiments. So I don't know if modern AI is of any help here. I hope it eventually will be, especially when it comes to, you know, structuring things on the conceptual level. But perhaps shouldn't replace talking to actual human beings. And then I think a very timely effort, again, relating back to that conversation, would be to think about as, as Shuai alluded to, I believe, building a sort of ideal curriculum for someone entering computational biophysics. I try to do this for my students. I try to give them resources from each one of those pillars. But of course, these are just handpicked books and, uh, selected readings that will never be fully complete. So maybe someone who's really knowledgeable should compile recommendations for the best textbooks and, uh, the best resources available for, you know, your well-rounded computational biologist and make them sufficiently popular that they would become a sort of staple, 'cause that's also the hard part. I would definitely love to see that. Another question that came up a lot was that of experimental computational collaborations driving our research, and this was brought up by several guests. It came up with Zan Schulten, it came up with Kresten Lindorff Larson, and also Yuji Sujita. Although in his case, it was more about international collaborations in general than specifically experimental people. But I think it's a very fair point. Very rarely we are capable of coming up with a truly great project idea completely on our own. Because the problem is, if we can come up with a project idea on our own, it often means that everyone else can do that as well, right? So to be first, you really have to be the one person who had a genuinely unique insight, and that feels much harder. And so very often we're better off partnering with someone who just encountered an unexpected experimental result or simply needs to look at an idea from a fresh angle. I think that is obvious. It's, you know... I'm not saying anything groundbreaking here. But what is interesting is, um, the way we approach selecting collaborators. Some of the stories we heard involve people, you know, being at amazing institutions and almost by accident running into other people doing cutting-edge work. And, uh, of course, it's never really by accident because these things happen to people who are prepared for such serendipity. But when we read these stories in, uh, journals or memoirs, it often feels as if those moments are somehow limited to a selected few who somehow always end up collaborating with the most technically advanced or creative experimentalists. And there's definitely some truth to that. I don't wanna disregard that. It's easier when your collaborator is next door than when they're on the other side of the world. But at the same time, many people emphasize that we're living in an era where distance matters much less than it used to. And, uh, maybe more importantly, I keep hearing stories from different directions that people are actually very willing to collaborate if you have a plan and a specific need or a specific tool. 'Cause we often imagine that everyone is too busy, and it's certainly true that everyone is busy in academia But if we bring something meaningful to the table, you know, something that genuinely enhances the scientific value of a project, people are often surprisingly open. And I think this is one reason why we keep talking about the need to make computational biophysics trustworthy, because experimental collaborators need to believe that we contribute non-trivial knowledge to a specific problem. And, um, if we can make that claim repeatedly over the course of a collaboration, then these international collaborators can be incredibly valuable. They're not always easy to maintain. There's a lot of day-to-day work involved, you know, constant reminders, making sure things don't slip through the cracks because we are all busier than we expect it to be. And, uh, we're probably all guilty of that to some degree. But as many people have said on this podcast already, if you find great collaborators, they can drive your research towards excellence and, um, you know, find collaborators. I'm repeating from Zan. Find collaborators who genuinely care about your contribution. They want to challenge ideas or mechanisms. They don't just hand you a finished analysis saying, you know, "Now please add some simulations to explain what you already know," 'cause, um, these don't bring much value. And, uh, yeah, it's not easy, but I think it's worth it in the end Another thread that came up a few times, and I think it was especially pronounced in my conversations with Ezgi and Jerome, was the idea of making things that are useful both to yourself and to the community. And this also foreshadows an upcoming conversation that I don't want to give away just yet. But there's a really important insight here. Many, you know, many tools for the community start from our own needs. So by, as practitioners, we recognize a need. Jérôme mentioned this when talking about developing a VMD plugin largely for himself to make his system setups more visual and, uh, you know, spot inconsistencies more easily. And the same idea goes back to my conversation even with Max Bonomi in season one, I remember. People create tools because they need them for their own everyday research. And if you're solving a problem that's important enough for you, there's a good chance someone else is facing the same problem. So the tricky part is that something, you know, that is perfectly sufficient for you and, um, you know, it follows a logic that you understand intuitively doesn't necessarily make sense to someone else. And this is something I've really learned the hard way a few times. It applies to the logical structure of a problem, it applies to the way you implement a solution, and even the names you give to things. Yeah, so to give a practical example, when I created the Molywood plugin for making molecular movies, there was always confusion about the naming of different components. So what I call an action or scene or simultaneity can mean different things to different people. So there's not always a universally accepted vocabulary for those concepts, or maybe vocabularies are just different in different, uh, subfields or communities. So you have to put a lot of effort into making things intuitive. And, uh, this is where this user interface design or user experience become really important. Companies are good at this because they have resources, right? They can hire testers. They can run pilot studies or programs. But we academics often struggle because it's hard to get meaningful user feedback. Not to mention the fact that, you know, improving the user experience isn't always rewarded 'cause it's published already. Um, it's done. And that's why I always encourage people, if you try a program and it fails in an unexpected way, please write to the author, assuming it's an actively maintained project. Tell them what you tried to do, what system you're using, what happened. You know, on GitHub, GitLab, you have all those issue reporting, interfaces. That kind of feedback is incredibly valuable. It helps developers identify failure modes they would never encounter themselves 'cause we can never test all possible configurations. And, um, honestly, those people who did not receive special training but just found your tool online and decided to start using it, these people are often the best kind of testers because they don't have any assumptions about what they should know. But going back to the original point, I think it's super important, even if painful, that we think from the user's perspective and invest some actual time in making useful tools intuitive and easy to use. Ideally, talking to people who try to use them without additional instructions, especially when people want to use them in non-standard ways, in batch mode or with modified systems or with non-standard residues or, you know, slightly unusual workflows. 'Cause a lot of scientific software is really designed around one specific use case, and, uh, then it fails in strange ways when you ask it to do something slightly different. Uh, and I know because we've spent the last two weeks debugging such a case with a student of mine. So here's where a little foresight can really go a long way. Um, then there's a question of knowing when a simple model is sufficient. This came up in conversations with Yvet Bahar and, uh, Kresten Lindorff-Larsen, and I again admit I have always been guilty of the opposite tendency. I tend to reach for the default solution, which for me usually means atomistic molecular dynamics or free energy methods, without necessarily asking whether they're the right tools for the problem. And, um, some problems might actually be better addressed with a coarse-grained simulation, bioinformatics analysis, or simply building a structural model rather than even simulating it. But I think many of us suffer from the same problem. You know, everything looks like a nail for a hammer, and this is not only about model complexity, it's also about the tools that we know how to use. So today, atomistic MD has become very accessible, so you follow a tutorial, almost anyone can run a simulation, right? But there are still many areas where setting up a successful coarse-grained simulation is far from trivial, and where using a bioinformatics database requires, for example, non-trivial knowledge of biology. So aside from maybe running something like a Martini simulation, which is very well documented and widely used as a force field, many models that go beyond atomistic representations are, you know, more cryptic. You have to understand their assumptions. Sometimes you have to compile the code yourself. Sometimes you need to understand the implementation before you can even begin. And so in many cases, we need to invest time in expanding our toolbox, and that effort can save us a lot of time down the line when we're trying to answer a difficult scientific question eventually. But, um, very often, especially when reviewing papers, you see cases where the solution isn't really adapted to the problem, and people try to extract information that simply isn't there, has no chance of being there. You can run a molecular dynamics simulation that if the event you're looking for isn't expected to happen on the timescale that you're simulating, then, you know, the whole exercise becomes largely pointless. and that's exactly the kind of thing Kresten discussed and before that, um, Paul Robustelli discussed in the context of intrinsically disordered proteins. Without sufficient sampling, you're often just looking at variations around your starting structure. Maybe it makes more sense to run a coarse grain simulation to get some sort of insight into that. On the other hand, um, Yvet talked about situations where very simple harmonic models and normal mode analysis can reveal surprisingly deep biological insights. And, uh, I'm always amazed by how much insights can come from these approaches. You know, this goes back to the first question of actually understanding the biology well enough to know what questions to ask. And again, this is a deep issue because once you know the right question, simple models can sometimes reveal broad organizing principles without requiring enormous computational resources. And, um, we often think that every problem can be solved by throwing more compute at it. But approximations that initially seem crude can, you know, sometimes provide an astonishing amount of insight. I came from a very strictly all atom background. I recognize that, and over time, I've developed a much greater appreciation for coarse grain modeling and elastic network models and again, approximate models. And a common criticism is that we only get out what we put in. But I think there's often a non-trivial mapping between a relatively simple input and a complex output. I've seen many times many of those relationships are highly non-linear and only become apparent after, you know, simulation or analysis is complete. So in hindsight, some of those conclusions seemed obvious, but they weren't obvious beforehand. And I think that's where the value lies in, uh, you know, building the model, running the simulation, analyzing the results, and looking for patterns, sort of guiding your brain, um, along the whole pathway of discovery. And, um, even if we end up rediscovering something that in retrospect appears obvious, you know, we probably would have never arrived there without going through the process in the first place. And then finally, something Ezgi Karaca mentioned in our conversation resonated with me a lot, too. She said that in these times when everything is changing so rapidly, PIs actually need training more than ever, meaning that we need to meet more, we need to have deeper discussions, and we need to exchange what we've learned about good practices in applying those new tools. There's going to be a lot of mistakes in this new era. There's going to be a lot of figuring things out. And, um, perhaps more than ever, the field is in a state of constant flux, so nothing is established again But it was really great to hear that bringing people together for something as seemingly simple as the summer school can produce results, you know, as profound as changing the standards of the field and creating new sets of good practices that different PIs can agree on. And I think it's going to continue this way, which gives me a great segue to my, to my little update on what I have been doing for the last couple of months, partly to justify the very slow pace of the podcast. so as some of you know, this has been a period where I moved from my position in Barcelona to my independent research position in Gdansk, Poland. And, uh, one of the things that has been on my agenda recently was pushing to create a CECAM node in Poland. I don't want to talk too much about it because we're still in a planning phase, but it has been a long-standing scientific dream of mine to become part of this community. I've attended so many amazing CECAM meetings over the years, and I think the best way to give back is to contribute some new events on our side. So we brought together a few people and started thinking about how to make that happen. Again, I cannot say much yet because we're still mapping things out, but here's my big shout-out to CECAM, the European Centre for Atomistic and Molecular Calculations, the original name being French. They're doing exactly what we've been talking about. So it's part of their philosophy to create events and workshops that bring scientists together at a really deep level and help uncover questions and problems that are often glossed over everywhere. And, um, in fact, CECAM was part of the original motivation for this podcast. Some of the really amazing CECAM meetings I attended in 2023 made me ask myself a simple question: Why don't we have these discussions in the public sphere? And it's true that these conversations probably work best in small groups of, you know, 30 to 40 people, which is the typical size of a CECAM meeting. And so in a way, this podcast is another attempt of mine to bring some of those conversations to a wider audience. But at the same time, I think it would be amazing to organize similar events in person somewhere here in Poland. So as I said, that has been my long-standing dream, and I'm happy to say that I'm doing my best to make it a reality. There are also many other things that have made me, you know, short on time recently. So as a new PI, the last few months have been quite crazy. Aside from finishing a few papers, as always, I suddenly found myself with many more responsibilities. I was hiring several people because I secured funding for the next couple years, and so I've spent a lot of time interviewing prospective PhD students, helping the postdoc deal with administration, relocation, starting to mentor master's students. Um, you know, I was writing more applications, I think something like four in the last half a year or so, just to make sure I'll have enough resources to expand the group and establish myself here. So it's a lot of work, but it's also incredibly satisfying work, I have to say. I haven't done some of those things for a while, and it makes me, you know, wake up every day with a sense of excitement and curiosity about what's next, how the projects are going to evolve and where things are going. A tremendous amount of work, but, but very satisfying. I also went back to teaching, so I was preparing materials for a couple courses, designing new subjects, and of course, actually teaching the classes. I often say that I miss teaching, and I still think that's true. It's just that teaching is always such an ambivalent experience. So depending on the particular interactions of the day, it can be both the best or the worst part of your week. But it does seem to be something I missed at some fundamental level. And, um, even though it's, you know, yet another thing piling on top of everything else, I still find it inspiring to be back to the proverbial drawing board. That's one reason why podcast recording took a bit of a hit I haven't been able to record as many episodes as I did during the last two years, and, um, to be honest, it's not even the recording itself that's the biggest challenge. The harder part is consistently sending invitations, sending reminders, following up, coordinating schedules, because everyone in the field is busy, and if you don't push and follow up, things simply slip through the cracks. You have to constantly remind people and organize and schedule and, uh, you know, send far more invitations than the number of replies you eventually receive if you want to maintain a bi-weekly or monthly schedule. So hopefully very soon I'll be able to make that more regular again now that things are becoming a little bit more stable. Certainly, the podcast has been a lot of fun, but it's also one of those projects that never quite reaches the top of the priority list, so naturally tends to suffer when things get busy. But I promise to keep it going and not let it fall behind for too long. I've also been recording video tutorials for Molywood-GUI, so, you know, check them out if you want to test out the tool. Let me know if you do. And finally, I wanna highlight that moving to a new place really gives you a lot of fresh energy. It gives you an opportunity to reorganize things and improve things. 'Cause after you've been somewhere for a few years, the environment becomes largely static and evolves much more slowly. So when you arrive somewhere new, you suddenly notice all sorts of opportunities for small improvements. And so one of the things I'm trying to do, and something that I encourage everyone else to do as well, is to use that fresh energy while you have it. Move things around a little, you know, reorganize things. If something feels strange or annoying or suboptimal or inefficient, it often takes just a small push to improve things, and, uh, people will appreciate it. Sometimes there are very small everyday things, you know, it's reorganizing the coffee corner in your department or cleaning up a storage room that nobody has touched for years. And there's really no better time to do these things than when you're entering a new environment or starting a new position. I hope I can keep this energy myself for quite a while, cause for now I seem to have enough to keep going. But Honestly, all of you help a lot with that. So the feedback I receive and the number of people who tell me, you know, "Please keep doing the podcast because it's valuable to the community," gives me a tremendous amount of motivation, and again, incredibly grateful to everyone who's listening. Very grateful to my guests. I'm also grateful to everyone who writes emails, starts conversations about the content or simply, you know, shares feedback. I think I already have enough ideas for an entire next season in terms of guests, but as always, if you have suggestions or people you'd like to hear on the podcast, I'm more than happy to discuss that. I think, um, yeah, that's going to be enough for today. We'll start season five in about two weeks, so stay tuned and I'll talk to you again soon. Thanks so much for listening. Thank you for listening. See you in the next episode of Phase Space Invaders