Enhancing Computational Fluid Dynamics Through Machine Learning Algorithms
Advisor: Anmol Bhardwaj
Internship Location: ASDRP (Ca.)
Onsite Mentor: Chris DeGrendele
Computational fluid dynamics (CFD) is a branch of computer science simulation that uses flow equations and partial differential equations to model fluid motion based on the
governing physical environments. Since computers revolutionized the design and innovation process, scientists have relied on CFD to model environments to predict turbulent or laminar
flow. Everything from the cars we drive to the HVAC systems that cool our homes rely on CFD to simplify costs and save time. At ASDRP, we hope to expand upon the field of CFD through
simulation of magnetohydrodynamics (MHD). MHD is a model that accounts for an additional flux being electric and magnetic fields. One such use for MHD are hall-effect thrusters which rely on accelerated electric fields to drive an ion thruster to produce propulsion. Currently, efforts to accurately simulate MHD have been limited due to high computational expenses. We hope to account for the many fluxes that drive MHD using high-performance computing (HPC) clusters. Previously, our group was capable of producing accurate simulations for very simple one and two dimensional fluid flows through coding advection, burgers, and Euler equations which provide a foundation for more complex simulations.
Project Blog
Post 1: Enhancing Computational Fluid Dynamics Through Simulation - Background
Computational fluid dynamics (CFD) is a branch of computer science simulation that uses flow equations and partial differential equations to model fluid motion based on the governing physical environments. Since computers revolutionized the design and innovation process, scientists have relied on CFD to model environments to predict turbulent or laminar flow. Everything from the cars we drive to the HVAC systems that cool our homes rely on CFD to simplify costs and save time. At ASDRP, we hope to expand upon the field of CFD through the simulation of magnetohydrodynamics (MHD). MHD is a model that accounts for an additional flux being electric and magnetic fields. One such use for MHD is hall-effect thrusters which rely on accelerated electric fields to drive an ion thruster to produce propulsion. Currently, efforts to accurately simulate MHD have been limited due to high computational expenses. We hope to account for the many fluxes that drive MHD using high-performance computing (HPC) clusters. Previously, our group was capable of producing accurate simulations for very simple one and two dimensional fluid flows through coding advection, burgers, and Euler equations which provide a foundation for more complex simulations.
Week 1: Particle Code - Week 1
As an introduction, I am working as a remote researcher for ASDRP, an organization based out in California that focuses on precollegiate research. I have been affiliated with this research group for over a year at this point and have been working under the same advisor the entire time. My mentor's project is broken up into 3 main groups: the simulation group, the aero group, and the machine learning group. As a member of the simulation group, my line of work primarily revolves around Computational Fluid Dynamics (CFD) and how we can solve them.
As for this week, I have been working on PIC (particle in cell) which entails particle interactions around embedded boundaries as they follow fluid cells. Essentially, I am building upon the ASCFD repository to create simulations of particle flow through a fluid grid around a given point. This kind of simulation is especially critical in modeling more complex sets of differential equations. The PIC code builds upon a lot of the older projects that my group has created such as an Euler's equations solver which is used to solve the differential equations that run the back bone of the simulations, and some of the old point detection code in which establishes the what the particles interact with as they pass through the fluid cells.
The goal for PIC is to create a simple precursor to solving a lot more complicated systems such as magnetic fields and plasma fusion environments that some of the other members of my group are currently working on solving.
Week 2: Addition of forces and momentum - Week 2
This week I have built upon the particle simulation code by adding particle to particle interactions. Now, each particle has its own mass and momentum which impacts how it interacts with the fluid environment, embedded boundary, and now each other as they get simulated. Each particle can now interact differently between each other through this addition that basically acts as a way to simulate different viscosities. Additionally, I have added what I have named a "bounce back multiplier" which determines how far back a particle will bounce after interacting with the boundary. This adds a deeper level of reality to the simulation by allowing the user to manipulate the results more through the addition of parameters.
I also finished laying down the main methods that the PIC code would use to simulate:
1) Shape and grid: while currently very rudimentary, the simulation takes just a simple shape that I have set to just a circle, and it uses a discretized grid that I can determine to create a boundary around the shape for which the particles can interact with
2) Flow field: the flow field serves to simply dictate where the particles would move in the simulation based on their fluid vector, since the current version of the PIC code runs in a 2 dimensional environment, the flow field simply takes u and v input for the fluid vector
3) Point detection: this builds upon a lot of the preexisting point detection code that we have created and will calculate when a particle will interact with the defined shape
4) Vector transform: this takes the point that of contact with the shape and will correctly update a particle's vector based on the normal and tangential vector of the particle with respect to the shape so that it will correctly bounce and interact with the shape after the collision, the particle should follow the generic flow based on its fluid cell following the particle's vector transform
5) Visualization: in the end, everything gets displayed in a series of combine frames that create a "movie" that displays the position of the updated particles as they pass through the time steps
Week 3: Enhancing of point detection - Week 3
This week I am building off of my particle code by changing the way that my I am simulating shapes. Previously, I relied on using some built in python libraries to define shapes, but now I am able to input an list of points in a matrix, and it will create a boundary around it. By updating this the PIC code is capable of handling two extra features. The first is the ability to change how many edges are present in the boundary, meaning that the shape can be more discretized depending on how much computational power I want to be expended. And the second advantage is being able to input much more complex shapes.
This takes advantage of some libraries such as the Path class from matplotlib.path, which allows us the define a 2D closed polygon. Once the polygon or shape gets created, we used our refined point detection method to return a what we switched to a Boolean to indicate whether the point lies within the shape. This uses a very naive version of what is called a ray casting algorithm which works by conceptually drawing horizontal lines from the particle out through the entire simulation grid and counting the amount of intersections it has. If this returned value is odd then the point is inside the polygon, if it is even then it is outside.
This is especially useful in comparison to some more numerical calculations since in a lot of cases if a particle is very close to the shape, a single update based on the fluid cell may be enough to cause the particle to skip over the shape without actually interacting with it since its updated position may be large. However, this method would need refining with much more complex shapes that may return values of 3 or 4 intersections. However, this can easily be corrected by changing how we view the intersections, and currently this is not a huge issue since our PIC simulations are just going around airfoils with a uniform flow field.
Week 4: Creation of Parameters - Week 4
This week, I am building off of my PIC code by creating a lot of the initial conditions within an inputs code cell so that a user can interact with the simulation and change the parameters. Previously, the PIC code was mainly set up to be run in a single box of code but in order for it to be uploaded and streamlined with the other files in the repository, it needs to be changed to follow a more strict format.
The elements changed are as followed:
point_in_polygon: this function takes two main parameters: point and polygon. These parameters represent a single particle's position at a given time step and the closed shape and its boundary respectfully. The function itself is a 1D array list that constantly gets updated
flow_field: this now gets called and defined outside the main section of the code so that it can be placed in a separate file that can be altered by the user since it is a parameter
update_particles: this function is responsible for moving and updating the position of the particles, then storing this so that they can be visually represented. The reason that this needed to be updated is since it takes "dt" as a parameter. The function itself also takes the parameter "particles" and is as follows: update_particles(particles, dt). The reason dt needs to be removed and defined separately is since it essentially functions as a time step for the PIC code and should be set by the user as parameter.
Visualization methods: all of these needed to be placed in a different block to be more inline with the other components of the ASCFD code.
Week 5: Integration with ASCFD - Week 5
This week I committed the work I have to my organization's GitHub repository meaning that I have to set up my PIC code for a virtual environment to ensure that it runs as expected. This mainly continues with what I had previously set up and I have tested the PIC code to ensure that it can function tangentially and can be properly called and run with the correct initial conditions and parameters. The main update that I had to make to the PIC code was to a lot of the visualization methods so that it can take elements of some of the other code in ASCFD.
The first change was to the "fig" and "plt.subplots" which creates the plotting canvas and axes. This takes a "figsize" parameter and in the case that we were testing it with, we set it to figsize = (8,8). The next change was to the "ax.set_xlim" and "ax.setylim" which is pretty self explanatory as it just sets the x and y limits of the grid. Next, I had to change the "shape_path" section that creates the visualization of the shape. Previously I was relying on some libraries to do this for me, but the resources to create and display the visualizations are available in the ASCFD repository. Then I updated the function "animate(frame)". This function is what creates the stitched up frames to create the "movie".
While these were all relatively simple updates since a lot of the frame work was already within the ASCFD repository, what created a lot of issues were the particles themselves. I had a lot of issues with them not correctly being updated which was strange since I did not alter any of the functions that dealt with particle updates. As it turns out, when I was saving the position of the particle for it to be displayed in the visualization, it would save and then get the next update without checking for an interaction with the shape creating a loop in which particles would skip over the point detection.
Week 6: HLLD research - Week 6
After completing the PIC code, I am transitioning to working on the HLLD (Harten Lax van Leer Discontinuities) section of our ASCFD repo before I start pushing anything. In short, HLLD is a type of Reimann problem and our group is trying to solve it by building upon the resources that we have already coded. Currently, our goal for ASCFD is to create a next generation hybrid MHD code to aid in Hall-Effect Thruster simulation and design. HLLD fluxes are an integral part to solving MHD Fluid Electron Loops which are a key architecture of effectively simulating Hall-Effect ion thrusters (HETs).
HETs are a new type of propulsion system that relies on the effects of some of the MHD methods to generator power. HETs work by work by using electromagnetic fields to accelerate ions, generating thrust much more efficiently than traditional chemical rockets. This is especially useful in outer space where having vast amounts of thrust is not necessary to facilitate movement due to the lack of external forces such as Earth's gravitational field and drag. While HETs are a powerful new technology, they face one major issue in simulation. For unknown reasons, they are very inconsistent since some of the electrons that get spun and ionized by the thrusters get lost.
Going back to some of the PIC code that I was working on earlier, MHD and HETs simulation rely on the much simpler particle in cell methods to allow for the kinetic behavior of the particles to be accurately tracked.
Week 7: Continuation of HLLD and MHD Research- Week 7
This week I am continuing to do research on MHD through literature surveys and by going through a lot of the papers that our advisor gave us. Tangentially, I went through a lot of the code on our repository that I was previously not very familiar with since I was working primarily of PIC this semester. While this was going on, we started working on some test cases to pose ASCFD against. However, an issue occurred when I tried to run sections of ASCFD remotely on my desktop. Previously, I have been using a VS code and my own virtual environment for coding. Somehow, when I tried to create another one the run other sections of ASCFD, it completely messed up python on my computer and I spent a long time trouble shooting. I tried reinstalling python on to my computer through power shell, but even that did not solve anything.
While not ideal, I ended up just switching to coding on my laptop on which I reinstalled everything and it seemed to work correctly. Working on my laptop is in some ways more convenient, but the hardware is not nearly as strong as it is on my desktop which increases run time for the simulations. Going forward, I need to find away to restore python and VS code on my desktop, or even possibly switch to an online IDE.
During my research, one thing that particularly stood out to me was a paper that introduced an Unsplit Staggered Mesh (USM) scheme for solving MHD equations. To summarize it simply, the new scheme incorporates constrained transport methods with high order Godunov fluxes and data reconstruction-evolution algorithms to achieve second order accuracy for MHD solving. The paper also goes into Modified Electric Field Construction (MEC) to deal with some of the issues I talked about in a previously regarding some of the inaccuracies in current HETs simulation.
Week 8: SSNCT - Week 8
Unfortunately, I was unable to attend our group and advisor meetings this week as I took a trip to Chicago to compete in the NAQT small schools national championship tournament for quiz bowl. For those of you know are unfamiliar quiz bowl it is a more competitive and team based trivia. Both teams get to hear a question and the first team to correctly buzz in and get the question correct gets to hear a set of bonus questions exclusive to them. On the team, I am primary responsible for fine arts.
In the preliminary matches my team went 9-1, only losing our first match to a team that we probably should have beaten but in the end it worked out. Our team record = advanced us into the playoffs where we placed 3rd over all in double elimination.
While our placement at SSNCT was a great accomplishment, we are still gearing up for HSNCT which is open to all high schools meaning that the field is going to be a lot harder.
Week 9: Blitz Talk Presentations - Week 9
The organization I am apart of regularly hosts what are know as "Blitz Talks" in which groups have an opportunity to give a 15 minute presentation about some of the research that they are working on. While they are not strictly mandatory, our group decided to sign up for one. During these Blitz Talks, up to 10 presentations occur simulations over zoom as the hundreds of participants are given the opportunity to jump around breakout rooms to listen to any presentation they choose.
As for our group, only the simulation group, of which I am apart of, decided to give a presentation. This week our group spent the time creating a presentation about our ASCFD repository. This semester, we presented on some of our major additions to the repository such as the new PIC and MHD code. Additionally, one of our group members who was responsible for some of the graphics on the repository itself made some more cool graphics for the presentation including a breakdown of our simulation architecture and timeline of what we are looking to include in ASCFD in the future.
Week 10: Presentation - Week 10
This week on Tuesday our group gave our Blitz Talk presentation. Like I said in my previous blog, Blitz Talks are a very diverse set of presentations and in my room, I got to hear some other interesting presentations about topics such as "Predictive Modeling for Rare Disease Diagnosis using ML/AI" and "Implementing eXplainable AI techniques with the Captum Library for Interpretable CNNs in Disease Detection".
Our presentation went as planned and after our presentation time elapsed, there was one question that captivated me. Another advisor who was in the bio-chem field asked about if ASCFD could be used for healthcare initiatives. The short answer to this is yes, it can be. ASCFD and computational fluid dynamics as a whole relies on partial differential equations (PDEs). PDEs are universal to every field. In CFD, we use them to govern flow equations such as in the previously mentioned Euler's equations, in economics they are used for option pricings in the Black-Scholes Equation, and in biology they can be used to model population balances of predator and pray. All of these scenarios are capable of being modeled just like our MHD, HLLD, and HETs speaking to the versatility and importance of simulations.