 Cross disciplinary project, we being the computer science students are trying to address the problems which mechanical engineering students face while solving their computational fluid dynamics problems. So actually they use C++ based open form software which is an open source software and it contains a rich set of numerical solvers, okay, form transfer field operations and manipulators. So actually what open form is based on C++ and for a newbie like very, very newbie person in the field of mechanical engineering, it is not the best way to start from C++ APIs. It might get tough if they don't have the proper C++ background, it might get tough for them to use open form. So Python flu addresses that problem. It provides an easy interactive Python interface to open form C++ reference APIs. So actually that was our main aim for the project, main motivation of the project. Actually Python flu was built five years ago and it was built according to open form 2.1.1 version and now the open form has grown drastically from 2.1.1 to 4.1. So we are trying to revive this Python flu package to the current version of open form. So Python flu needs two packages installed before we install the Python flu. It is one is conflu which is a common configuration package. If we run that package we can be sure it installs all the dependencies which are required by Python flu in the system and the second the managed flu what happens is the biggest limitation of open form C++ object solvers are if any one of the sibling object solver object dies unexpectedly then the whole solver crashes and what happens is many a times the simulation is running for six or seven hours. So if that rare incident happens then the whole simulation is gone for nothing. So managed flu provides a C++ layer of managed open form objects. So we need these two things conflu and managed flu for before installing Python flu. So why we cannot allow the null pointers the null solvers is because in Python we cannot afford to have those C++ null pointers. It can be deadly nightmare it can cause any system problem. So that managed flu is required. So while managed flu was built it was built according to keeping in mind the structure of open form 2.1.1 and Ubuntu file structure of 12.04. Since then the Ubuntu file structure has changed drastically also the open form has changed some of the header files some of the source files drastically. Some are totally removed some of them are merged into the other source files some of them are renamed some of them are relocated. So we try to do that thing that making this Python flu compatible but the main problem we encountered was this is the structure for open form 2.1.1. There is a particular reference header file called porouszone.h and mrfzone.h which has some specific fluid dynamics related task which we don't know yet because we have we have we are given a chance to abstract this project but the same mrfzone.h does not exist in open form 4.1 and this is just one example. So we tried to make the new mrfzone.h in open form 4.1 to make it work so we tried to take that mrfzone.h in current open form and make it work with Python flu. But what what has happened is since last five years the constructor for mrfzone.h object has changed from one parameter constructor to four parameter constructors and since we are computer science students and we don't have enough background in fluid dynamics we don't know what to do about those three uninitialized parameters. So that was the main reason that our project was got blocked multiple referenced fields. So we we just know the main abstract thing. We don't know the exact details and our our mentor professor Prabhu also said that you don't need to go into details because this this is not going to help us anyway. We have to just we are just given requirements and we have to make the software. So we instead we tried to do this in form extend 3.2. So form extend is a family based on open form 2 series. So we thought that since this this changes were untraceable we thought that form extend 3.2 might be a better way instead of open form 4.1. But in the form extend 3.2 you can see that these files are present. But again that one parameter constructor is sent to two parameter constructors. So we went through all the logs 3000 to 4000 lines of log while we compile this open form it takes six to seven hours of compiling plus this managed to also take one to two hours of compiling. We are mentor set set and went through whole logs but we could not find any proper reason. So our project got blocked there after five to six weeks. So immediately we changed our project to automated parameter variation in any CFD system computational fluid dynamic system and real time plotting for those systems the parameter plotting for open form. So open form was two point something five five years ago four point something yeah no no no the open form 4.1 is like working correctly. Because we could not yeah no no no actually there is another layer of python package called pyfom which does many great things like changing the dictionary files all the CFD system. The python flow was python APIs but pyfom is just a container for open form it just runs the open form solvers as its sub processes it does not care about how is it going to handle those C++ APIs it's it's just going to run them as a sub process. So pyfom does great things for us it plots the data real time there is a thing called residual in fluid dynamics computational fluid dynamics as we are using the numerical solvers we are committing crime the numerical crimes like we are we are bound to have some particular number of digits to represent as our mantissa and in floating point numbers we cannot we don't have the big size to store the exact number so we are committing numerical crimes. So it is bound to produce errors so those due to those errors the solver might sometime diverge rather than converging to a single solution it may diverge so those results are very important while the while one student is performing the simulation. So on the fly pyfom allows us to plot those results. So what we have done is also there is a thing called there are some some parameters like viscosity relative tolerance if you change those parameters the system the system might get some in some way optimized. So we need to change those parameters for a given range of value and save those plots and try to analyze them that for which value of parameter the system is going to be optimized. So we have tried to automate this thing rather than any CFD student changing those dictionary files the the CFD dictionary files are just a file representation of the system parameters initial values and the other things we have tried to automate the changing parameters also we have tried to save those plots and put them in a tech file directly no no optimization in the sense for a given parameter if no no no in any physical system for some some contour for a particular value of parameter the system might behave optimally. So we are to guess though guess that range and in that range that we have guessed no no no the the CFD student will give that as input and will save the plots append them in a tech file and generate the automated report for them. So that's the work we have done in last week also there is a working demo for that our so we also support real-time dictionary changes see in the the parameters are stored in nested dictionary format. So we have stored them as a graph in where each internal node is a nested dictionary and we have tried to search that if the parameter exists in a graph or not and we have tried we have used the depth-first search algorithm for that and change its value and this is our live demo. I think it's okay if you don't show the demo okay in your particular case it's okay I'll tell you why none of us understand anything about fluids okay whatever you show is going to be going to be a bouncer okay and I completely believe you were the first person who does not need a presentation. You are fit to be a prof okay you are sat there without looking anywhere you went on blabbering blabbering blabbering and you talk logically. Thank you sir. I have done a course in fluid dynamics. I have also done fluid dynamics I have forgotten everything about it. So there is a ICO foam there is a solver called ICO foam for which stands for incompressible This is our script PyFoam underscore automated we are changing the end time for the simulation from the two to three. So it will start the simulation it will plot those things in real time if the simulation is carried for a long time for say for a two hours it will be plot real time. These graphs are saved in a tech file which I have just closed and I will compile that tech file the PDF will be generated which can be later used for analysis of the simulation and this is the compilation of tech file and that was for end time simulation we can change the tolerance which we allow for numerical errors. So in the next example I have changed the tolerance which command yeah which command yeah the first PyFoam underscore automated.py is my script yeah which uses PyFoam and some my some algorithms which help me to get those parameters and change those parameters while the simulation is doing. So this is the first thing is my script the second thing is the file there may be some parameters like viscosity of the system yeah yeah because it's the need no no the for suppose the for viscosity from two to three two to three in the interval of point one you want to observe and for which viscosity the system behaves optimally then my script allows you to do that yeah that's automation for parameter variation yeah but for yeah so that's the second would be the files name which I want to which the parameter is located in which I want to change the third thing would be the total path that these are nested dictionaries so for that file in the solver dictionary there will be a key called P it would be in itself a dictionary which will have the parameter called tolerance I want the tolerance to be in 10 is to minus five to five into 10 is to minus five at the intervals of 10 is to minus five so I'll do that iteration on the go using the icofoam solver of open form so if I in this case I have typed the wrong parameter because it is solver slash P slash tolerance so it will give me the error and when I type the correct path it will start the simulation so it's real time just the parameter changes the lots will come on the fly yeah the backgrounds are the logs which open form generates for us to see what is the pressure value what is the velocity value what are the current numbers and etc so that was our project then the future word there are some parsers which I can make for particular dictionary files also I can add specific commands for some specific open form solvers and I can make those report very much interactive so that was our project any more questions if so actually the parameters are located in a very nested dictionary so I have made a graph like representation for each internal node is a nested dictionary and leaf nodes are the single key value pair so for that I have generated all kinds of corner test cases to check whether whether a full path exists or not suppose I given system slash p slash some parameter name and if that path does not exist then I'll produce the false error that parameter does not exist so I have tried to cover the whole depth first search test cases for that thank you