 Sumit is a student of privacy journey. So, Sumit is doing his master's in the University of Colorado Boulder and he will the next session is by Sumit and it is on turbulence modeling. So, Sumit, you can start your session. Good afternoon to everybody. Today I'm going to demonstrate the procedure to compile a custom turbulence model on open form version 7 using 1 to 18.04. The sessions based on the work I did under Professor Janani Mam's guidance during my undergraduate studies as part of the FOSC semester long internship. Due to open form being open source and free of cost, it is possible to study the source code in detail and implement custom versions of solvers, turbulence models, etc. In case of RAN's turbulence models, different turbulence models are suited to different types of flows. For example, k epsilon is suited to a certain type of flow, k omega is suited to a certain type of flow. In some special cases, none of the existing turbulence models suit the flow case in which case you have to modify one of the existing turbulence models to actually fit that particular flow case. Of course, it's impossible to implement all such modifications and corrections into one single software. Hence, it is it is beneficial to know the process to compile a custom turbulence model. Today I'll be showing the process to compile the k epsilon model. We will not be making any changes to the source code of the turbulence model itself in this demo, but I will point out at which stage of the process one can carry out modifications to the code. There are some limitations and restrictions. This procedure was developed for open form version 1906 and not version 7, which is what is being used. But the file structures in both cases are compatible. Hence, we can go ahead and use this process for open form version 7 as well. Due to the pre-compiled version, since we are using the pre-compiled version of open form, any change in the version of Ubuntu or any of the dependent libraries may cause the process to fail. So in this case, I will be using Ubuntu version 18.04. We have tried this process with version 20.04, but it did not execute successfully every time. Workshop participants who are using version 20.04 or above are free to try the process, but there is a possibility that it may fail. And also the code dependency for each turbulence model is different. So this process is only restricted to the k epsilon model in case one wants to compile a different turbulence model, the process will be different. Okay, so let us start with the process and switch back to the slide view. First of all, we need to navigate to the working directory of open form and copy the source file for the k epsilon model. To that end, we need to copy paste these two lines in the terminal. Now we have copied the turbulence model files into this directory, which I am showing here. Now the next stage is to actually change the name of the turbulence model because obviously we cannot have two turbulence models with the same name. So let us enter this new directory that we have created. Now we will rename this turbulence model as my k epsilon. Now the folder name has been changed. It is now my k epsilon, but the file names inside this folder is still k epsilon. So we will need to rename the files inside as well. There are two files inside this folder. There is a header file and there is the actual source code file. I will show the same. So in this my k epsilon folder, we have k epsilon dot c, which is the actual source code file and k epsilon dot h, which is the header file. We need to rename both of these into my k epsilon so that it corresponds to the folder name. Ultimately, that is what the name of our turbulence model is going to be. Hello, one small doubt. Could you tell me what is this p and h file? The c file is the source code file, which actually has the source code for the turbulence model and h is the header file. So there are multiple code dependencies. You have to have the mesh data. You have to have the solver data. So all those declarations are contained in the header file. Also, there are several member functions in the source code file for k epsilon. And each of those member functions is declared in the header file. It is more of a coding thing rather than anything physical. It doesn't have a physical connotation per se. It is all coding structure. I'll rename this file k epsilon dot c to my k epsilon dot c. Similarly, I will also rename the k epsilon dot h file to my k epsilon dot h. Now, if we check, you can see that the files have been renamed. However, there is still one thing that is left. The k epsilon, we have renamed the source code files, but the class declaration inside that file is still k epsilon. We will need to change that to my k epsilon as well because that is the name of our new turbulence model. So for that, we will have to insert this command. All instances of k epsilon in the dot c and the dot h file will be replaced by my k epsilon. This is the usage of this command. So let us go and insert it here. Now, if we will open any of the header file or the source code file, we will see that there is all the class instances are called my k epsilon and not just k epsilon. As you can see, all instances of k epsilon have been replaced by my k epsilon. Now, at this point, if there are any modifications that one needs to carry out in the source code, it is possible to do that. So for example, if somebody wants to change the model constants or add some new functions, this can be done over here. This is the part where you can actually modify the turbulence model. Now, once we have created the turbulence model of our choice, we need to actually link it to the open form installation and compile it. To that end, first of all, we need to copy a file called turbulenttransportmodels.c. Now, what this file is, is that it contains a list of the turbulence models which are to be compiled by the compiler. It is a file of macros. So let us go ahead and copy this file into our new directory. I have one small doubt. Yes. Overall, what I understood that you have written your own code and you are trying to compile this code with the open form environment, right? Yes. Okay, thank you. So we have copied the required files into our custom directory, into our new directory. So let us go into that directory and rename turbulenttransportmodels.c. So turbulenttransportmodels.c will tell the compiler which instances of turbulence models are to be compiled in the main install directory. We will rename this file to my turbulenttransportmodels and it will tell the compiler which instances of turbulence models are to be compiled in our new directory. So basically, in this new directory that we have created, we can have n number of different turbulence models. I will just simply copy this file and rename it. So turbulenttransportmodels.c will become my turbulenttransportmodels.c. Okay, now here what we need to do is open this my turbulenttransportmodels.c file and we only need to tell the compiler to compile my k epsilon.c. Hence, we will delete all the other lines in this file and just keep these two lines in the file. So at the end of this step, this is all my turbulenttransportmodels.c should contain. Let's go one step back into the incompressible directory. Now, we need to actually link the new turbulence model to the central openform install. So I will go to explorer. So we see this make file here. In that, we have two files. In the make folder, we have two files, files and options. Now, these are the files which actually help link the turbulence model to the central openform install. So let us open files. So once you open files, you will see all these lines here. We need to replace these lines by the given lines that I have here. So the files folder, so the files file should contain only these two lines. So we will copy these two lines and insert it into our files file here. At this point, you have to be very careful with the spacing of spacing and indent because with these sort of files, it's very critical for the compiler to understand. Let us open options. Now, we need to add three additional lines here. So these two three lines here at the end of exe underscore ilc and lib dot underscore libs will link the new turbulence models to our existing openform installation. Again, at this point, you have to be very careful about the spacing indent and the presence of this backslash here. It has to be exactly the same way. At the end of the step, files should look like this and options should look like this. Now, there are very few steps remaining in this process. So first of all, we need to give the compiler a directory, an ll include directory where it can actually store the files related to compilation. So for that, we will copy this line and insert it in the terminal. Now, it is simply a matter of typing w make and the model will compile. Depending on the system you have, it may take a little longer. So you can see that there is no warning or error message and that means that the model compilation has been successful. To test whether our model works or not, let's do a trial run. What w make ll include does? So w make ll include specifies an ll include directory for the compiler. So the compiler on compilation generates some files and it needs to know the location to store those files. So we are going to be storing those here in incompressible. If I type explorer.exe, you will see that there is this ll include directory. Here is where all the files generated during compilation are stored. W make is just the end command to compile the model. So to test whether our model works or not, let's go back to the main user directory. What I have done is I have copied the PITS Daily Openform Tutorial Example into this directory in the run directory. Now, to use this new turbulence model, we need to make two changes. First of all, we need to go to constant and we need to change the name of the turbulence model that is specified in turbulence properties. So I have changed the name of the RAS model to be used. It is since our turbulence model is named MyCapsule and that is what we will write here. This is the first stage that we have to do. The second change we have to go to control it and we have created now a new library of incompressible turbulence models and that is now called MyIncompressibleTurbulenceModels since our turbulent transport models file has been renamed as MyTurbulenceTransportModels. So this last line needs to be included at the very end of control dict. These are the only two changes that we need to actually use our new turbulence model. Note that we haven't made any changes to the source code of the turbulence model itself so the results will be exactly identical as those with the standard k epsilon turbulence model. What exactly this line means? So basically we are invoking this new library that we have created. We have created a new library called MyIncompressibleTurbulenceModels. So in order to use this new turbulence model, we have to invoke that library first. It's sort of analogous to writing hashtag include some library when we are writing a C++ code. Does that answer your question? Okay, so let us go ahead and run the simulation. It is not 100% compiled. Actually the thing is OpenForm is written in C++. So the entirety of OpenForm is compiled using a GCC compiler. W make is a compiler which is built on top of GCC specifically for OpenForm. So there is nothing in this procedure which is outside of OpenForm per se. Okay, so let's type simple form. Now the simulation is running but I want to point out one thing here. If you will see the name of the selected turbulence model here will be my k epsilon and not k epsilon. And if you see this message here that means that the model is being used in the simulation and the simulation has also finished successfully. Let us use Paraform and check the post processing results. Let us check the velocity field. You can see it is exactly identical to what one would have if we were using the k epsilon model because obviously we haven't made any changes to the source code of the k epsilon model. So basically this is the process to compile a custom turbulence model in OpenForm. If you are using a different version of OpenForm for example version 8 or version 9 this process will be different because the file structures for those versions of OpenForm are different. This link here can give you some insight as to the process to compile a custom turbulence model for those versions. Thank you. So thanks Suman. So does any one of you have any questions for Suman? Of course this link will be shared with you and I think you can try and replicate it and try and make changes but would you happen to have any questions? So if you want to change something in the code because we haven't changed anything just rename it and change. Can you show some changes and then compile? Okay it's very simple to do that. So we've been through the entire process. Actually my concern is dependency. If some dependencies comes in between then how we can resolve it. So again that's the pitfall with this method. Since you're using a pre-compiled version of OpenForm we don't know on which system it was compiled as in what versions of which libraries it had what operating system version it had. The ideal method would be to actually compile OpenForm on your own system. That is the failsafe, that is the foolproof method and it will work every time but compiling OpenForm on your system will probably take upwards of 2 days because of course OpenForm has multiple solvers, multiple turbulence models etc. But in terms of simply changing constants, adding some filter functions it generally works without issues. Let's say I want to change the constant which is the function of temperature. Let's say for example. So one thing that you have to notice we are using incompressible turbulence models here. So it's a barotropic flow so we won't have any temperature dependent values. I'll do one thing. I'll go back and I'll make some small changes in the code and I'll recompile. That way you can see it works even without. And it would be a function of something, some variable, pressure, temperature. I just want to see that. Okay, let's see if we can do something. I'll try to see. So the way I use this process was I was trying to modify a trigger function for intermittency generation in a transition turbulence model. So that is a function of multiple different things including some boundary layer specific parameters and it worked in that case. So I'll come back to my terminal here. So this is the source code file. I'll do one thing. I'll open it in a different text editor. Okay. So you can see that there are many protected member functions for different things. There's one function for correcting your eddy viscosity. There's one function for your source, source for turbulence energy, turbulent kinetic energy. There is one source term for the dissipation rate. And then we have the constructors here which are declaring certain constants. Now with this, what happens is if the constants are coming from a fixed dictionary of constants, coefficient dictionary, and that is protected. It can't be accessed. So if I change that, it will not compile. However, what we can do is I'll try to see if there's something else that I can change. This is the epsilon equation. So this is the part where we are actually writing out the transport equation for the dissipation rate. Yes. So this is the finite volume method library inside openform. So this carries out all the finite volume operations such as computing the divergence, computing the gradient, computing the curl if it's there in any place. And FV options is the library which will allow you to add an additional source term or a distraction term inside the equation. You can use FV options within control date and add a constant source term into your turbulence model. These lines, they basically are for relaxation and utter relaxation according to the simple algorithm. This is for constraining the values of the turbulent kinetic energy so that the turbulent kinetic energy doesn't assume, let's say a negative value or some garbage value. This is the equation for turbulent kinetic energy. Again, it's basically the same framework. And at the end, we invoke correct new T or basically this protected function right here. We are just updating the value of the eddy viscosity because at the end of the day, k and epsilon, so that the eddy viscosity is a function of the turbulent kinetic energy and the dissipation rate or k and epsilon. Yes. What I'll do is C mu is 0.09, it's a constant. I'll just multiply it by 2. I'll go back to the W make directory. I'll put W clean so that we'll clean the previous compile that we did. What I'll also do is change the timestamp of the turbulent transport models or C files that we have. So to that end, I'll first go into the directory, change the timestamp, go back to incompressible. Again, we will have to specify the directory again in this case. Note, if you try to compile something like let's say the k omega ssd model, this process won't work because k omega ssd in itself is dependent upon k epsilon and k omega. And k omega ssd itself is a base class for other turbulence models which are built up upon k omega ssd. So you have to be careful in that area. Again, you can see that the turbulence model is compiled. So I'll just go back to the fits daily case. Now, there is a high possibility that the simulation may just crash because we have made a. Yes, yes, actually validating the model, but let's see. Again, it took two iterations more than normal. Let us just get it actually use the turbulence model that we have created here. Yes, yes, yes. Okay, so it's using my K epsilon, which means, of course, it's our turbulence model. Let's check with the post processing. This may be non-physical because it will be non-physical because obviously the relation between the id viscosity and the turbulent kinetic energy is wrong in this case. So it obviously looks a little different. Yes. So you can make similar changes. You can add a separate function and then invoke it within the class where you are actually solving your k and epsilon equations. There are many possibilities. You can check out this reference that I have mentioned here. They can definitely be of help. Thank you. You're welcome. I have one question. The process that you showed here, is this a general one? Like if at all you want to make any change. Right, so as I mentioned, this will work if you have Ubuntu version 18.04 and open form version 7. We've tried this process on Ubuntu 20.04, open form version 7. It worked most of the times, but some trials in it, it was just inexplicably, it didn't work. So I wouldn't say that it will work every time. It may not work. That's basically this entire issue is an issue because we are using a pre-compiled version of open form. The process was designed such that you will be using a compiled version, a compiled source version of open form. So you will compile each and every solver and turbulence model in open form on your system as opposed to just downloading a pre-compiled version. But that option of compiling that source is only possible if you have very high performance computing setups because it takes well over two to three days at a stretch. But for the open form version that I have shown and the Ubuntu version I have shown, it should work fine. No, what I meant was, suppose like if I want to, the tutorials that the most we had so far, we had used the turbulence. Yes, you can use the turbulence model that we have created. You can use it in any simulation you want. Just that you have to make the two changes that I have described, changing the name of the turbulence model and writing that last line, invoking the incompressible turbulence model library. Yeah, I understood that but my question was not regarding this. I was asking a general question. Suppose if instead of like, like tell, we are in the demos, not this demo, like the previous in the morning, there was some demos where we had this turbulence intensity. We were like giving some percentage of the velocity right at the inlet. And if instead of that, if I want to give some realistic velocity profile at the inlet, is this the same procedure or something else? No, no, it will be different. It will be different. So that is Abin's question, I think. If I were to want to change anything in the main solver, as opposed to if I want to add an equation, or I want to change an existing solver with, you know, add another term in the equation, is the procedure overall, which you said, of course, I'll take into account that, you know, turbulence files your access because you're modifying the turbulence. But if I were to add an equation or add a term to an already existing equation, typically, is this the procedure that you will follow? Generally, the overall workflow will be the same. But then the way we link the solver back to the central install, I think that will be different because the dependencies will be different in that case. Okay, by dependencies, you mean the library files? Yes, ma'am. So for the turbulence model, we will just need the mesh tools library and the finite volume options library. But then the solver will also, I think, have some runtime parameter libraries and some other dependencies. Okay. Now coming back to Auburn's question. So that's solvers. Now, if I want to change certain input parameters, or if I want to change properties of the fluid to be quite variable, this is of course not the procedure, right? You would go and deal with something else. Yes, ma'am. I think ma'am, what he means is he wants to assign a different velocity to each cell is what I thought he was trying to say. I want to implement a different boundary condition. Right. So again, the dependencies are different for that. So yes, it won't work with this process. The general workflow will be the same. So copying the files to a new directory, making your changes, linking it to the central install and setting up the compile parameters and compiling. But the way you link it to the central openform install and then the way you actually compile will be different. So one more. Yeah, please. Just wanted to know, like, is there any reference or a link that you shared? Does it contain the information related to this or is it only specific to the problem that you discussed now? No. What I have shared, it's mostly specific to the problem I have described here. But I think maybe if you check out the second reference, it may have something that you need, the second reference here. Okay, okay. Yeah, I will look into it. Yeah, but please note it's based on version 8 and not version 7. So one question is from my side. Okay. So if we want to change the thermo physical properties, of course, there are some models already defined like k is the function of t already we can give. But if something else we want to give in the thermo physical properties. So can we do that? I mean, can we change that in the solver and we can do that or what we should do? So I think thermo physical models is described in the constant folder, I believe. So there are different thermo physical models in open form as far as I know. Again, it's similar to the solver question that was asked. The process, the general process will be the same, but then the specifics will be different. So the way you link your new thermo physical model to the central install, that will be again different. But the process general workflow will be the same. Can you share some references where thermo physical model have been changed in the source code? I don't know of such, but maybe you can just check this reference if it might have something. I don't know, but you can try. I have one small question. We are using different FBA schemes, right? Yes. Suppose I want to develop a new scheme that is not available in open form. So I just want to ask whether it is possible the way you have shown the same process that I'm supposed to follow or difficult and easy to compile? See, the thing is, if you will open one of the finite volume scheme files, it's actually very, very complicated in terms of code dependencies because one code is relying on the other code, which is relying on two other codes and so on and so forth. It's fairly complicated and I don't have any experience in that regard. But like I said, the general process, copying your scheme to a new directory, writing your scheme up, linking it to the central install and then using it, those will be the steps. But again, the dependencies are different. The code will be different. So the specifics will be different. Like I said, the same process won't even work if you're trying to use the Komega SSD model. So the general row is the same, but the specifics are drastically different if you're going to do something like that, I think. So essentially, what it is trying to say to all of you is, so he had to spend several months trying to figure out which are the dependencies for his particular problem which worked. So he used to keep compiling and there used to be a compilation error then he'll add certain dependencies and solve the issue. So maybe you have an overall, so the idea of this particular session was you get an overall view of what things you have to address. But then you go back and to your specific problem, figure out the dependencies which files are absolutely required for compilation. So that is absolutely essential. Shubham, to your question about input parameters properties, I think transport properties openform gives you a certain number of options to change your input parameters. Maybe a tabular column of details or maybe a polynomial fit. So there are certain limited options available. There are certain other things like, for example, let's say, let's say, so there is probably a viscosity model which I might want to change, but the viscosity changes not with temperature but with something like shear rate. So that means that I am probably getting for every simulation or every time step I need to get the shear rate and my viscosity might have to change with that. So that means, again, this process what Sumed says applies. We had to figure out what libraries are interlinked to this and then recompile the thing. So it is pretty much the same, but again, the dependencies of which libraries are interconnected to your viscosity model and your shear rate model should have to be found out. Actually, I am working on the phase change problem. So with phase change, suppose something is changing, like density is changing or thermal conductivity is changing. So that phase change we are representing that melt fraction alpha. So with alpha, if it is changing something, thermal conductivity, so how we will incorporate that? Essentially, this is the process, but you will have to figure out the dependencies. We have done, you are talking about solidification and melting. So this is a process, but you will have to figure out the dependencies. Base is the solver. Now the problem here is you will have to choose the solver, what library files are there in that solver and deal with it. We were facing a problem where version 7 had a particular solver. The same solver in version 8 or 9 had different libraries. So then the model that we had implemented in 7 will not compile in an 8 or a 9 even if you are using the same solver. So that means the library files, all of those dependencies you will have to sort out. Of course, that is something specific to your problem. Thank you. Ma'am, one resource that he could use is the Doxygen documentation files for Openform are available online. So they have these kind of tree diagrams where they show their dependencies in a flowchart kind of way. Maybe he can use those and see what dependencies are there and what he needs to actually work on. Okay. Can you just type that in the chat box, the Doxygen link if you might so that people can access it? Yes, ma'am. I'll just find that link and I'll share it here. Okay. Pile, yes. So it's 340 and we can take a 10-minute tea break. So 350, we come back and we will have the session on GUI for Openform BlockMesh by Rajdeep Adat.