ACM ByteCast - Amanda Randles - Episode 22

Episode Date: November 30, 2021

In this episode of ACM ByteCast, Rashmi Mohan hosts 2017 ACM Grace Murray Hopper Award recipient Amanda Randles, the Alfred Winborne and Victoria Stover Mordecai Assistant Professor of Biomedical Sciences at Duke University’s Department of Biomedical Engineering. She is also Assistant Professor of Computer Science and Biomedical Engineering and a member of the Duke Cancer Institute. She has received the National Science Foundation Career Award and was selected as one of the 10 researchers to work on the Aurora Exascale Supercomputer. Her visionary work in simulating blood flow through the human body in a system called HARVEY, led her to be featured in the MIT Tech Review Innovators Under 35 list. Amanda talks about growing up in Michigan and being inspired early on by her high school computer science teacher. She talks about her passion, which lies in using the largest supercomputers in the world to answer questions otherwise left unanswered, and her Duke research group’s focus on building large scale personalized blood flow simulations. She also discusses her 3-year involvement with IBM’s Blue Gene Team, where she learned how to debug programs and identify and work through problems collaboratively, and her time at Harvard University, where she learned about fluid dynamics and started writing HARVEY from scratch. She also describes the fascinating contributions her team made to address ventilator shortages during the early days of the COVID-19 pandemic.

This is ACM ByteCast, a podcast series from the Association for Computing Machinery, the world's largest educational and scientific computing society. We talk to researchers, practitioners, and innovators who are at the intersection of computing research and practice. They share their experiences, the lessons they've learned, and their own visions for the future of computing. I am your host, Rashmi Mohan. Reeling from a global pandemic and its impact on our healthcare systems, we have often paused

to wonder how we can improve outcomes for patients with a plethora of technology solutions at our disposal. The marriage of biological sciences and high-performance computing is one such discipline that is integral to this area. Our next guest is a pioneer in this field. Amanda Randles is the Alfred Winborn and Victoria Stover Mordecai Assistant Professor of Biomedical Sciences at Duke University. She's been the recipient of the National Science Foundation Career Award, Grace Murray Hopper Award, and was selected as one of the 10 researchers to work on the Aurora Exascale supercomputer. Her visionary work in

simulating blood flow through the human body in a system called Harvey led her to be featured in the MIT Tech Review's Innovators Under 35 list. Amanda, welcome to ACM ByteCast. Thank you very much. Amanda, I'd love to start with the question that I ask all my guests, and it's always fascinating to hear folks, you know, the journey that people undertake as they get into the field of interest that they have. If you could please introduce yourself and talk about, you know, what you currently do, and also give us some insight into what brought you into this field of work. Sure. So I'm in biomedical engineering at Duke University now, and our research program is really focused on building large-scale personalized blood flow

simulations. So I'm really passionate about using the biggest supercomputers in the world and figuring out how we can leverage them to answer questions we wouldn't otherwise be able to answer. And I've probably been working in this space about maybe 10 or 15 years at this point. And I would say that what really started even just getting involved in computing in general. I grew up in Michigan. I went to a math and science center in high school where half of the day, people from around the district got together and we would take our science classes. And we took computer programming in high school. And I had just a phenomenal computer programming teacher back as a freshman in high school that really got me excited about programming. And through that program, I was exposed to really strong science, kind of the connection of how you can do computational modeling, how you can use the programming side.

I was part of the first robotics team in high school. And it really just all of those kinds of experiences got me excited about, you know, how do we use technology and what can we do with it? When I got to Duke, I was really interested in physics and taking a physics-based approach. So I started actually majoring at the time I started with political science and was thinking about, it was time when they were doing all of the genome and trying to think about international law associated with genetics. So I was really interested in the mix of policy with science. But I started out in political science and physics, and I realized how much I missed coding. And I just, I really enjoyed, you know, nights where you stay up all

night coding problems. And I really liked the hands-on coding side of things. And I was, as a freshman in college, some of my friends were taking coding classes, and I kept trying to help them with their homework and just kept realizing how much I actually really missed it. So I ended up double majoring in physics and computer science. And I think everything I've done throughout my career has really been at this kind of intersection between different disciplines of how do we take the physics-based model, how do we couple that with the computer science side? And I've always really been interested in how we apply that to biomedical questions. So really taking this physics-based approach and answering different bio-based questions. So in undergrad, I worked in a few different genetics labs and I was really involved with some bioinformatics projects. And I

would spend some time at the bench, some time doing research with the computational side and kind of slowly realized I was much more excited about the days I was spending on the computational side and tried to spend less and less time with the bench. I'm not as strong on the experimental piece. And I guess just through that, I started getting more and more involved in the computer science. And when I graduated from Duke, I was offered a position at IBM to go work on their Blue Gene supercomputer. And at the time, I hadn't really had any exposure to high-performance computing. I didn't really know what a parallel computer was.

I didn't really have any experience at that stage. But when I joined IBM, I was really lucky to get to work on one of the, this is right at the height of the Blue Gene L transition to Blue Gene P, where they were creating the biggest supercomputer in the world. And it was really exciting to get to play with that kind of technology and get to work with that. And one of the jobs I had was trying to get applications to run faster and port different biological applications to the supercomputer and try to identify how do we optimize them

and make them more efficient on these systems. So I got to learn a lot about computational modeling and how you tune a code for these large scale systems and really just the power of these large systems and how you could run simulations on so much of a larger scale than you otherwise could have. And through my time at IBM, I started to get very excited about the applications and what we could do on the biomedical side, which kind of led me to go back to graduate school because I wanted to kind of shift away from being the one building the supercomputer to being the one who was really using the supercomputer and really setting up those questions and driving the questions and the research agenda, which is really what motivated me to go back to graduate school, where I did get the PhD in applied physics, really focused on the physics-based model and how we, you know, how we develop these physics-based models, but the entire time kind of addressing biomedical questions along the way. So it's always been an interest in this marriage of like the computing side with the physics and the biological application. That's a phenomenal journey. I mean, and also, it sounds like you identified that intersection of those, you know, three areas early on in your career. And what I also found

fascinating was that you started an industry and you actually chose to go back to academia, post that once you discovered that, you know, you were you wanted to be the person using the supercomputer rather than building it. But I'm sure the, you know, the exposure that you wanted to be the person using the supercomputer rather than building it. But I'm sure the exposure that you had in building the computer itself gave you some ideas of its capabilities and its limitations. Did that play into your decisions at all? And how has that assisted you in your journey so far?

Yeah, I think I was incredibly lucky to be a part of the Blue Gene team. Just in general, it was just such a unique time period in parallel computing because that was right when the US was taking over as number one in supercomputing and they had just created this Blue Gene system that was being put at Lawrence Livermore National Lab. There were days, I remember having to go in early in the morning, just had to have the opportunity to boot 64,000 processors and how exciting that was

before people in California got up to be able to just turn on the system and do that kind of thing. It was a really great atmosphere where we had phenomenal people who were working on all aspects. We had the control systems team was amazing. The MPI team was amazing.

We had really strong teams, but it also was a system that was kind of, you know, we were working on the system, developing the system. So if a code wasn't scaling or a code didn't work on the system, you didn't know if it was because you had ported it incorrectly or if it was because, you know, we hadn't finished, there was something wrong with the hardware because it was still being developed or there was something wrong with the underlying software stack. There are so many places

where that could be going wrong and it was because everything was just in flux. So it really taught me a lot about how to debug programs and how to address, you know, how to identify problems and how to work with people from, you know, the entire, you know, both the hardware and the software stack and try to find like the, how do you really sort out where the problem is and how to build a piece of software that's actually going to scale well and all of that. And that played in, it was a really good experience from that end of like, what do you need to think about and how, you know, don't just think about developing a software or a code base.

I think a lot of people, you know, you don't take into account the hardware piece and how, like, you know, how much memory is there? How do we make it fit on the system? How do we optimize it for the system? So when I first started developing Harvey, I came at that from, you know, really building it to be tuned to scale and be parallel, like be efficient from a parallel computing standpoint with all of that in mind. And I think that that's really paid off and been very helpful. And then having the industry experience before going to graduate school was also, it made like, I knew why I was going to graduate school. I knew, you know, what I was interested in.

I was very directed. I think it made me much more efficient when I was in graduate school. And it helped me, you know, kind of come in and hit the ground running of, you know, why was I there? You know, I had a full salary. I had a, you know, I had a house.

I had a car, like everything as someone working in software industry and leaving, you know, a nice salary from IBM to go back to graduate school. Like there's a reason you're choosing to do that. You know why you're there. And I think it gave me a lot more purpose of, you know, I knew what I was trying to accomplish and why I was there. And I think that was very helpful.

Yeah, I think that's an excellent point that you bring up, because I've often heard from friends that, you know, the journey of graduate school, especially when and when you're going into research, I mean, a large part of your time is really trying to understand what is it that you're trying to solve, right? Even to get to that, that core question that you want to answer is a large part of that journey. And it sounds like you had a little bit of a head start because you were very keen on, you know, you knew what that transition was like for you and why you were going back. But speaking of Harvey, you know, I mean, it's hard to read about your phenomenal work and not mention Harvey. Could you tell us a little bit more about it? Like, how did it come about? Where

did that idea even germinate for you? So while I was in graduate school, I had joined Tim Kekseris' lab at Harvard. And his research was really... He's a very strong multi-scale physicist. And he uses those kind of techniques in a wide variety of areas. And I think, again, I've been very fortunate in the exposure that I've had, where he had a project going where he had just started a blood flow project probably the year before I joined the lab. He had strong collaborators that were the founders of the methods we were working with, just absolutely amazing people that were spending time in the lab while we were there. So they were trying to get this blood flow project kind of up and going and there was room for a graduate student to join it. So I joined the work on a code called moofy and through that i had a lot of exposure and i really learned about fluid dynamics because i had never taken a fluid

dynamics class and i learned about the problem of what do we need to you know what do we need to know about how do we build like what what are the questions we can answer with a fluid dynamics code base and why do we need this and because we were in Boston, we had strong clinical collaborators at the hospitals nearby to really understand what is the potential power of personalized fluid dynamics. And in that, we kind of hit the end of the road of what we could do with the original code and kind of hit the limit of how do we scale the code? How do we run larger simulations? And so I went back through and kind of started writing Harvey from scratch as a graduate student based on some of the other work that we had been doing and used some of the same fluid dynamics algorithms and based on the

same methods, but really tried to write Harvey from scratch with the plan to parallelize it and try to make it scale as well as it could on these large supercomputers um which is part of you know harvey is the william harvey is the person who discovered that um blood flow circulate that blood circulates through the body so we named it after harvey and as well as at harvard so it was somehow that all that all made sense um so we have harvey kind of came out of that and in the beginning har Harvey was just, it's a code where you would take in the 3D geometry that you would get from like medical imaging. So from a CT scan or from an MRI scan, we use commercial software to segment

that medical imaging data. So by segmenting it, you're pulling out a 3D geometry. So you're getting that 3D geometry representing like your coronary arteries. And then we would, Harvey takes that as your input. So you have a 3D geometry of the vessels and runs a fluid simulation to identify the velocity, the pressure, different quantities like shear stress. And those are quantities that are associated with the development and the progression of heart disease. So this gives you an opportunity to non-invasively, so you're taking a CT image of the patient,

you pull out that 3D geometry without ever having to do anything invasive. And then we can get at quantities like the velocity of their flow, the pressure, the shear stress, and kind of get diagnostic metrics or predictive metrics of what could happen to that patient. And in the beginning, we were completely looking at, in Harvey, it was a bulk fluid parameters. We've kind of built that up from there where we have, now we've added a fluid structure interaction. So we have, you know, millions of red blood cells that can be modeled at the same time. We're looking at how cancer cells move through the body, looking at the adhesion of cancer cells to

the wall. So we're really built the really built the complexity of this code up over time and really tried to scale that as we go along. I mean, there's so much to unpack there, Amanda. But, you know, I'll start with the very sort of naive or simple question. So if I have Harvey, you know, and I actually have, you know, CT scan information and MRI information as a doctor, could I just plug that into Harvey and get results where I can actually, you know, determine what my treatment should be for the patient in front of me? Does it work at that

level of, you know, I don't know, I mean, at that scale? Yeah, so we're trying to make it as user friendly as possible. And I guess I should say one positive thing for listeners here that are by having strong software engineering practices in place, that has been critical to making Harvey be able to grow and be successful and even be usable in any way in the clinic and make sure, you know, if someone's working on the cancer project, they don't accidentally break something from the heart project or something like that. But with that, we do have kind of a series of ways to interact with the data. The way, if you, from a clinician standpoint, I'm trying to, there's kind of, you know, there's a wide range of projects, some that are much more translatable

into the clinic and some that are much more basic research. There are, the most straightforward way for clinicians to interact at this stage, there are questions like, should they or should they not place a stent in the coronary artery of a patient? And currently, the gold standard for that is fractional flow reserve. So it's a quantity that's really just a pressure gradient across a narrowing in the vessel. And if that pressure gradient is above or below 0.8, that will determine if the doctor should or should not place a stent. There are currently FDA software packages, FDA approved software packages available where you

can take the CT scan of the patient, you run a fluid simulation, and you use that simulation to calculate something like the fractional flow reserve. And you now have a metric that you've gotten non-invasively of the patient. And you can determine should you or should you not stent the patient based purely on this fluid dynamic simulation. So questions like that are ways where the doctors can interact with these types of simulations much more easily. To run a simulation directly in Harvey, you do need to do that first step of the critical

piece is creating that geometry that's going into Harvey. So we use commercial software to segment the geometry from a CT scan. We have other software packages and collaborators we work with to develop, to create 3D reconstructions from angiography. But there is that manual step of how do we extract the 3D geometry from the medical images. But once you have that, that would be the input into Harvey. And we did have a really great student that worked with us the year between his undergrad and he entered an MD PhD program. And in the in-between, he created a tool that is a user interface for Harvey that allows you to take that geometry and you can actually modify the geometry in any

way that you would want. So if you want to do some surgical treatment planning, so identify, you know, if I placed a stent in this vessel, what would happen? So you change the geometry by placing a stent or removing the narrowing in the vessel, and then it will remesh that geometry and then automatically launch it into Harvey so that the user doesn't necessarily have to use the command line programming, know how to use a large scale supercomputer, and that would all happen in the background. And then when the simulation is completed, it will retrieve the results and allow you to visualize the flow field. So there are easier ways for users or clinicians to interact with the data. And there are fun features where that can, you know, he did build

this so that it could work in virtual reality. So you can actually, you know, immerse yourself in, in the blood vessels and, and, you know, do this using an Oculus Rift or a Z space or any other kind of semi-immersive or immersive experiences as well. Wow. That's, that's amazing. One of the things that you mentioned, and so I'm just trying to understand this a little bit better, right? So as if if I were and I know I know that there are two parts to it now I probably asked both my questions as a clinician like what kind of if I were to use this system um even in you know in the in the state that is I understand that there's much more to it um that you have to work on in terms of you know actually developing the geometry. What kind of compute power do I need

in order to be able to run this? Right. So it really varies based on what question you want to ask. And we're kind of in an exciting time period. We're working very closely with different cloud providers like Microsoft and Amazon to try to see how do we actually port Harvey into the cloud and make this more usable? Because that's kind of the direction we see this going in the future of the way this would actually work in a clinic is having is using cloud based resources. We're not expecting every hospital to own their own supercomputer. You know, it's how do we how do we make this tractable? So a lot of our work is at the basic science side, we use a suit like the large scale supercomputers. But we also want to push it and see, see you know if we put absolutely everything into the model on these big when we're

using the production runs on the big supercomputers what can we take out and how do we minimize that and what is required like how patient specific does the model have to be do you actually have to model all the red blood cells and what for the question you're asking what needs to be included and we want to minimize that so that it can be more tractable to run these simulations. So you can run, depending on the question, it can be something that you could easily run in the cloud on even a few GPUs, and you could run it for under an hour and be able to calculate something like a fractional flow reserve. When we ran, we were the first team to run the full, with the full arterial network in the body. And that was like from, you know, from the head to the toe, everything, one millimeter and above that took the entire like 1.6 million processor supercomputer at Lawrence Livermore lab, if you wanted to run that at cellular resolution.

So it's kind of that spectrum of, are you trying to run an extremely large region? Are you looking at, you know, do you actually need all of the red blood cells? But for what we're putting in practice, you know, what we hope to put in practice in the clinic would be more identifying when can you do, like, when can you use bulk fluid simulations and likely moving things into the cloud and running on that and making it much more tractable and affordable for clinicians and hospitals to actually use. Got it. Thank you for that clarification. My second question was, so obviously there is also, I mean, I was obviously talking about,

at the clinician's sort of environment, but there is a large part of your work, which is really dealing with getting the large volume of maybe data, that medical imaging data that is available out there to do more research and understand, like you were talking about, you know, understand, you know, some of these medical problems in more depth and possibly, you know, drive that, use that research to drive, you know, better solutions, right, whether that's on the medical side or on the computing side. What are some of the biggest sort of challenges you're seeing with that side of the world, both, you know, interesting computing problems that you're trying to solve or scale

challenges that you're running into? I'd love to hear more about that. Yeah, that's right. I think the area of personalized simulation, it's incredibly exciting right now. There are so many opportunities for people to jump in and help in so many different fields, which is, it's really ripe for other people to jump in, which is great. We have many challenges and we need a lot of assistance. So there are questions, you know, we're kind of at a great time point where, you know, we're seeing the explosion of machine learning. We're seeing the explosion of AI. We've seen a lot of fantastic work, really applying machine learning to questions like segmentation of getting out that geometry from the medical imaging. And while all of that's kind of

becoming very mature at this stage, we're really at the beginning of seeing the connection of machine learning with physics-based models. So you have like George Karndiakis' work at Brown is, you know, he's doing a lot of physics inspired neural networks. And we're seeing, we're starting to see that connection of the physics laws with machine learning to see what we can predict. But with that, you need to have large scale populations, you need to have a lot of medical imaging data, we need to have, you know, a lot of simulations completed. If we want to bring in anything from the fluid simulation standpoint, we have one fluid simulation, you know, when we talked about like the full body model that took the entire, you know, one of the world's largest

supercomputers, and we took the entire supercomputer to be able to do that. It would be difficult to run a huge parameter study and create, you know, 500 different patients where we've run the entire simulation. So it's trying to figure out how do we balance that? How do we actually make so much data? And then some of the issues that we're kind of running into on a daily basis, even with one simulation, it's the work that we're doing with Aurora, the upcoming Exascale system.

We want to be able to, we're running the simulation so we can analyze the data, visualize the data, and actually understand what we're doing in the simulation. Each supercomputer has several petabytes of memory across the entire supercomputer. Our simulations are using that entire supercomputer for every single time step. And we are running millions and millions of time steps. So you can kind of see that we are creating every single time step, we're creating five petabytes of data. It is not tractable to just

download all of that data for the entire simulation and do post-hoc analysis. It's really becoming necessary to have in-situ visualization techniques, in-situ analytic techniques, even in-situ machine learning training options. We really need to be able to analyze and work with the data while it's still on the system. So that's the crux of the project we have going with Aurora is trying to set up and investigate some of these in situ options because we're really hitting the point where it's just not tractable to download that much data and do any kind of post hoc analysis. That's a huge part of it. We had one project recently where it was, you know, we ran something for maybe four or five time steps, like, you know, just a very small subset. And we still had about 400 to 500 gigabytes of data that we were trying to just visualize to see, you know, where did the cancer cell, where was it placed? How did this get set

up? And just trying to, you know, how do we actually just get one image and snapshot to see what's happening with 400 to 500 gigabytes of data. So I think like the amount of data we're creating is exciting on the front of, you know, we're creating a lot of data that can feed into these new methods like the machine learning side. But it also brings a lot of challenges for how do we actually deal with it? And how do we, you know, what do we do with all this data? How do we access it? How do we actually get it off the supercomputer in a way that is usable and tractable? Aside from actually trying to build large scale population databases with, you know, whatever disease area you're trying to look into. We've been very focused on trying to augment patient data with also

synthetic databases, meaning taking one coronary geometry and modifying the radius of the vessels in there slightly and creating 15 different versions of that patient with slight modifications to the geometry and having a large-scale synthetic database that really allows us to pinpoint the effect of changing the radius or changing the angle between two vessels and what does that do to the resulting fluid dynamics. So we can do all of that. We require large-scale computing and we need to be able to create large-scale synthetic databases that are inspired by the patients, but allow us to really identify and pinpoint different factors. We've also been very interested in how do you combine questions like design of experiments

with machine learning and fluid dynamics results where, you know, when we're looking from the clinician's perspective, they want to have a full view of what's happening with the patient. So you could imagine it's not just, you know, how the patient is sitting there at rest and what their pressure gradient is going to be. It's, you know, are they going to be at risk if they start running? Are they going to be at risk if they start running at high altitudes? Like what if they go to Denver and they're running and what if they're pregnant or like, you know, what if there's so, there are so many different factors that could play in and could change someone's hemodynamics that you can't just measure in the doctor's office. And that's the power of having these personalized flow simulations that we can

actually simulate each of these cases. But again, it's not really tractable if there are an unlimited number of different examples of someone running in cold in the winter. And there are many different scenarios you can imagine. And we can't do an individual simulation for each of those situations for each patient that comes in. So we had one large project trying to look at the design of experiment approach of can we identify the minimal number of simulations we would need to run to be able to couple that with machine learning to then predict

what would happen in all of these other use cases. So trying to find intelligent ways to make the most use of our supercomputer hours and get the most out of them and really couple it with these new metrics and these new algorithms to try to make that go as far as possible. You know, as you were talking about, you know, machine learning and like the amazing, you know, set of challenges that this field has to offer. But the machine learning piece was especially interesting to me only because, you know, we talk so much about, you know, using machine learning carefully and biases introduced into the data that could impact what your outcomes could be. What do you see as things you if you think about bias, I mean, you know, you get an advertisement wrong on the internet, you can probably bear that loss, right? But the field that you're working in, there's very little room for error. So how does one mitigate risk? That's a really great question. It's definitely been an issue that's really plaguing this area because you see there have been countless papers already where it's bias you didn't really

appreciate that was in the data makes transfer of that method to other datasets or other hospitals. They're not able to replicate the same experience or the same kind of results. And it oftentimes comes from unidentified biases and things like that. We need to really... I think that's where the focus on the shift to interpretable machine learning methods. We don't want to view this as a black box. We need to understand why it's making the decisions. Why are the recommendations being made? What's happening under the hood and what's going on there is incredibly important. From our end with the validation piece, we've kind of built up where it's been very important to understand what are the critical components and what could be, you know, where do you have to validate? And we've started aside from doing anything on the machine learning piece of just how do you actually validate these flow models?

Because anytime you see a physics-based simulation, you should be questioning why should I believe this? And is it accurate? And we started working with a team at Arizona State where they would take that 3D mesh file that we got from the segmentation and they would 3D print the mesh file. So we'd have a phantom or a 3D printout that represented someone's aorta or their coronary arteries. And then they would run a controlled flow experiment within that aorta and within that phantom. And the nice part there is they were able, you know, they knew the viscosity of the fluid,

the inflow, like everything is a very, very controlled setup. And they're able to actually measure using particle image velocimetry, like the velocity flow field, like the entire flow field, not just one measurement in one time point of what was happening with the the fluid within the phantom and we were able to compare the measured velocity flow fields with what we're getting out of the simulation to make sure that we

were getting the right results and we're actually capturing you know vortices that may appear and really complex flow print like profiles and make sure that we are getting that correctly in our models. And for us, we really, we started that, I mean, we started, that was one of the first major projects we tried to do once Harvey was kind of up and running because the first question is like, how do you, why should you actually believe us? And we started with the aorta because it does have, you know, it has such a high Reynolds number, which means it's closer to turbulent flow. The flow in the aorta, it's like the aorta because it does have you know it has such a high reynolds number which means it's closer to turbulent flow the flow in the aorta it's like the aorta is one of the largest vessels and it has very high velocity flow so it's very chaotic and the thinking was if

we can get the aorta correct then everything else will be much easier so we started with the aorta and tried to compare there but we we did have to think through you know every time we start looking at a different vessel we start thinking we start have to think through, every time we start looking at a different vessel, we start thinking, we start looking at different disease areas. We do, we start over and we do another 3D phantom. We print it out. And so we've looked at the core,

we've had coronary phantoms, we have femoral artery phantoms. We've now started working with a team at Lawrence Livermore Lab where they're bioprinting microvasculatures and doing the same in that space to make sure that we're actually getting the right flow profiles in the geometries and the length scales and the flow regimes that

are relevant to each of these different disease areas. And then beyond the preclinical work, we need to compare against results in the body and see what are we missing? There are many assumptions that go into the phantom. So having direct comparison with what we see in the body is incredibly important. We've just finished up a large clinical study where we had 200 patients at two different sites where we have, where we looked at this quantity that I mentioned of the fractional flow reserve, where they actually put a wire in the patient. They invasively measured the fractional flow reserve over the stenosis. And we're comparing the measurement that they got from the guide wire to what we have in our simulation. So we're able to really ensure that we're getting the right results and matching what

is happening in the body. And I think finding ways to validate the model in that setting, we have, you know, from the cell models we're working on, we work with in vitro experiments, we ensure, we kind of, we do a lot of work trying to replicate optical tweezers or like how you're pulling red blood cells make sure we get the right mechanical behavior how they're moving through constrictions if we get the right passage time and we do a lot of work kind of replicating known experiments in our simulations to ensure that we're modeling everything accurately and that is it's very important to kind of take that into account and make sure you have the right validations in place

for whatever research question you're trying to ask. Yeah, no, thank you. That was very insightful. I was reading a little bit about the idea of, you know, digital twins used in medicine and how that sort of is helping the world of personalized medicine, right? And then I think the point that you brought up about actually, you know, 3D printing the parts that you're actually working with to ensure that you're able to validate it, that seems to, you know,

that makes perfect sense that you actually want to, you know, you have a digital twin, you use that to, you know, to test out your theories, but then you also validate it using this, you know, the physical, the phantom organ or piece that you're testing out. Does this mean that this whole area is now becoming more affordable, Amanda, for us to, I mean, is this something that will scale from a cost perspective as well? I think so. It is, it's definitely becoming more affordable. And I mean, we're also kind of piggybacking on the side of like, we are seeing an explosion of like HPC technology in the cloud. It's getting easier and cheaper to use these options in the cloud. Some of our code,

we have looked at options, you know, we are running on GPUs, we're running on CPUs. We've also started looking at running on like ARM processors, which are often much cheaper to run on in the cloud. So I think we're also getting that trade off of depending what question you're asking, your time to solution versus the cost side of it. And we have a lot more flexibility to see, can we use slightly slower processors that might be cheaper and might only take an extra half an hour? Do an hour, but do you really, you know, do you need it to run in that half an hour? Is it okay if it takes 90 minutes? And depending on the question, we can, we have some flexibility on that end, but as computing gets cheaper and things like the cloud and processes are getting faster, you know, we're kind of riding that whole wave still.

And we're able, we're able to make this a bit more accessible to to other researchers as well and all of that has been has been a really good really good progress for this kind of work got it yeah you know one unique part of your career um that i observed was how embedded you are with you know various external labs or consortiums or industry partners why is this so important to you so right yeah our work is is very interdisciplinary um so we really do i think it's very unique in our lab at least where you might have a call with you know a hardware vendor one week and then be in you know the imaging lab at the cath lab at the hospital the next week. It is, we have to kind of understand the full spectrum and work very closely with the right people.

And we are trying to be on the cutting edge. We're trying to use the brand new supercomputers with brand new features that we don't really know. They're making modifications to the hardware all the time. How do we best exploit that? So we work very closely with the hardware vendors to understand how do we best exploit that so we work very closely with the hardware vendors to understand you know how do we write our code to run as efficiently as possible on your system so we work very closely you know with the intels with microsoft with ibm and that side of it

and the students in the lab really they can talk across that whole spectrum which i think is pretty unique and pretty pretty pretty great from their end. And then every single project we work on has someone like has a clinician or a researcher, like it has, you know, a domain expert or the user invested in it. So, you know, I think a lot of times it's easy for the physicist or the computer scientist to come up with questions that we think are interesting and are exciting. But then when you go and tell the clinician about it, they're like, yeah, but that would never work in practice. We would never use this. And we kind of, you know,

we have regular interaction with the clinicians to make sure the questions that we're asking are actually useful to them and that the tools we're developing for them will be something that could work in the clinic. We have, you know, when we're looking at this virtual reality tool, we've conducted a lot of user studies in the cath lab to try to understand, you know, how would you actually use this? Why, you know, how do we make this usable for the clinicians? What are the best ways to do that and make it not just, you know, some kind of kitschy tool we have, but something that could actually be usable in the clinic. My postdoc was at Lawrence Livermore National Lab. And we still work very closely with the teams at Lawrence Livermore because they're fantastic.

They're kind of in the middle where they're physicists and PhDs in physics that are really, they're very used to working with the large-scale computers. So from the application standpoint, they're some of the best people in the world for knowing how do you get a physics-based model to scale on these big supercomputers? So it's, you know, we're working with the applications experts, the hardware vendors, and all the way through to the domain user and trying to make sure we're kind of touching on each of those pieces and pushing that along. And being able to communicate across those boundaries has been very important. Yeah, it sounds like the absolute right thing to do, right? I mean, definitely having the ear of your customer, if you will, because they're the ones who are actually going to be using the products that you put out is so critical. And it's also, I think, a great's very important because there are just basic things of i'm trying to think of an example yeah just just basic ideas of you know we're trying to identify

a tool that we think is helpful or we say you know if you could get this bifurcation angle or you could put in a stent in this location having the doctor come back and be like that's great but you know stents only come in these four sizes or you know like these are the restrictions that you may not have thought about um or you know there is actually only come in these four sizes or, you know, like these are the restrictions that you may not have thought about. Or, you know, there is actually a vessel in the way we wouldn't be able to do that. Like having them kind of keeping us honest and making sure points that we may not, we may not realize that come into practice when you're actually in the operating room or like the time that you have to spend and what, you know, there are, there are just, you know, questions and parts that as a computer scientist or as a physicist, we don't

really realize about the real day to day of how they can use these models. So having them involved has been incredibly useful. There are definitely questions that have come up that we find interesting, and then the doctors help tune that and say, well, actually, this would be what would be incredibly helpful for us. And we kind of come to the middle and try to make sure we're asking questions that are actually useful. Yeah, makes a lot of sense. I also heard about your recent work during the pandemic around ventilator use, right, and helping physicians determine the optimal sharing of ventilators. So a couple of questions I had around that is one, you know, if you could tell us a little bit more about, you know, what was the work that you did there, but also how easy is it for you to pivot into, you know, addressing an imminent challenge? This is not something maybe that you would have anticipated prior to the

pandemic. So, you know, how easy is it for you to sort of, you know, use the work that you've spent years sort of building expertise on to address a problem that's right in front of you that might be slightly, you know, I don't know, maybe applied in a different way. Right. Yeah. So the ventilator work was actually, you know, it was very interesting in that sense of, yeah, I guess just for some background, I'm sure everyone's pretty aware, you know, early on in the pandemic, one of the first issues was the ventilator shortage. And we're seeing that in the news every day. And the question really came out that we had a significant ventilator shortage in the US

and worldwide, right? And one of the teams at Duke on the medical side, they jumped in immediately and were trying to find ways to increase ventilator capacity. So their hypothesis was you could take a ventilator and if we could split it between two patients or even more, we immediately have a way of at least doubling our ventilator capacity and making the ventilators that we currently have go farther. So they developed a device that was tunable that would allow you to, it was a 3D printed device that would allow you to split a ventilator between two patients. And the interesting piece was it was any two patients.

So they didn't have to be matched in terms of weight or lung compliance or any other features of the patient, which also was what had been going on in the state of the art. So they were able to expand it so that any two patients that came up, you could tune this tool and use it to split the ventilators. They came to us because we had worked with them in the past on fluid dynamics projects related to the heart and blood flow simulations. And they were asking if we could develop a way to tell the doctors, how do you actually tune it when you have two different patients? We have this new information. How do I take two brand new patients and identify the optimal setting for this ventilator splitter?

And it was an interesting project of, I think we were probably, they came to us within the first week of when we had locked down in North Carolina and everyone had stopped coming into work. I think we were all kind of sitting there hoping, you know, you really wanted to make an effort, like wanted to contribute and wanted to find some way of helping, but I honestly, I couldn't see at the time of, you know, how would, how would computational fluid dynamics help the pandemic? You just kind of wished you could be helpful. And so I think everyone in my lab was very excited when this opportunity came up and they kind of jumped right in. So we had a large team that really started meeting every day and we have, we had a phone call each

day to go over how are things going? What hurdles did you run into? How do we help you? But we actually started out having two different teams working on projects. So we had one that was trying to pivot immediately with Harvey and see, could we like, do we need a 3d model? How do we use a 3d model? And I won't go into the technical details, but just from, from the high level, this is very complicated because there's a fundamental difference of like, we we're, we're modeling a fluid, like a liquid. And, um, looking at the airflow is, um, it's actually very different how you're going to do the computational modeling of that. So the first questions, can we even pivot Harvey into an airflow model? And then the other team was set

up of, you know, ignoring Harvey, could we start from scratch and create a very simple one dimensional, um, like lumped parameter model to represent the ventilator and the lung capacity and everything? And in the meantime, the team from the medical school was creating a benchtop model and getting the data that we would need to validate against. They were using mechanical lungs, completing the experiments and getting that data. So we had full team meetings every day to check in. If we had a model working, what data would we need to validate it and make sure we had all that running in parallel? We're very fortunate in that

the low-hanging fruit of having the new 1D model worked incredibly well to match the data. We were able to shift focus to that. It was interesting in that it was a completely brand new model we had never worked on before. People were able to draw from their experience and knowledge of the fluid dynamics to build this model. But it was actually a brand new model to us

and something new that they, you know, within two weeks pulled together, validated, and had ready to go. And then the other piece of that project that was just really worth noting and very interesting was you can kind of imagine there are many different patients that, you know, if you have many different patients, you know, someone could be, you know, 100 pounds, someone could be 120 pounds. There are many different patient parameters that could come in and kind of explodes very quickly of the number of the different simulations you might want to run. And to submit this for FDA emergency use approval and have everything available for the doctor so they weren't waiting on any simulations we wanted to have everything simulated before ahead of time so we had the results for every possible combination available and that meant running millions of simulations so we actually submitted a proposal to the hpc consortium for covid asking for compute time um and we kind of put the pie in the sky idea of like, it would be amazing

if we could run all of these simulations. So we asked for like a million compute hours. We're like, this would be great. And we assumed when we submitted it, that we're going to get some subset of that and have to cut it back and run only a subset of the simulations. We submitted the proposal on a Monday.

And by Thursday, we were paired with Microsoft to work on the Azure cloud setting. And by Thursday, we were paired with Microsoft to work on the Azure cloud setting. And by the following Monday, we had actually completed 800,000 compute hours and run every simulation that we wanted to do and were able to go through the entire parameter sweep and had that completed within a week of submitting the proposal itself. So I think just in general, it was a really great example of bringing an interdisciplinary team together to really accomplish something in a time constraint where we really needed to get it forward. Within three weeks, we went from never having worked with this model before to developing the model, validating the model, and running the entire simulation. So everything was kind of ready.

There was a company in the area that donated their time to create a mobile phone app so that the doctors could access the information and work with the data on that end. And it all just really came together very quickly. And, you know, I think no one slept the weekend that they were running all the simulations, but it was great that everyone was willing to put in that kind of time and effort to really make this happen. It was so heartening to hear that that kind of partnership and the amazing things that comes out from that kind of commitment and getting these, like you mentioned, the diverse teams together to solve a really crucial problem. So thank you for sharing that. This has been an absolutely captivating conversation for me, Amanda.

For our final bite, I'd love to know, what are you most excited about in the field of biomedical engineering or the work that you're doing maybe over the next five years? Yeah, I'm really excited to see, I think at this stage, we've validated the models

in a lot of different spaces. We've started collecting a lot of data and we're kind of ripe to both, you know, have this marriage that we've talked about with the machine learning of how do we move this further? But then how do we move into spaces we weren't able to go into before? So we have a lot of the work in our lab is focusing on looking at cancer metastasis

and trying to understand the interaction with circulating tumor cells when they come off the primary tumor, they're moving and might make a metastatic site. And we're only now able to complete simulations that are able to track a cancer cell on the order of centimeters or longer distances that are really necessary to be able to understand where a cancer cell may be going. And in the similar vein, for the cardiology projects, we're now able to run simulations where we can look at not just a heartbeat, but trying to understand, can we predict longer time periods? Can we look at, you know, the grand challenge of what happens over the course of, you know, even a day, but it would be amazing if you can go to like weeks or months. And I think by coupling with these ideas

of physics inspired neural networks and other ways of tying into the machine learning, we're able to look at much larger spatial domains and much larger temporal domains that are really allowing us to ask questions we couldn't ask before. So I'm excited to kind of see, you know, with as we shift to using systems like Aurora, and we have so much power that we haven't, you know, haven't been able to have before, and tie that in with these new algorithmic changes. I think we're able to see, you know, how does it, like, what is it about a certain cancer cell that causes it to move in different directions? Can we really understand those underlying mechanics driving treatment options, new potential to really address how do we help address different disease areas and improve outcomes for these patients? I think we're really moving beyond the validation stage and getting into how do we start expanding the use of personalized flow simulations for different disease areas outside of just coronary heart

disease and conventional cardiovascular work. Got it. Yeah, I'm super excited to continue to follow your work and learn more about what you do. Thank you for taking the time to speak with us at ACM ByteCast. Thank you very much for having me. ACM ByteCast is a production of the Association for Computing Machinery's Practitioners Board. To learn more about ACM and its activities, visit acm.org. For more information about this and other episodes, please visit our website at learning.acm.org slash bytecast. That's learning.acm.org slash b-y-t-e-c-a-s-t.