[devansh.purohit]

Hello
I am new to the research field. I am working on my own so it is very difficult to find the correct way. Thanks to this forum which helps a lot.

I have a question.
How do i connect my geometry file to my solver file?

for example: I make a geometry in freecad or catia. I can export it in any format so maybe in stl which is very common. Then I made a solver using c++ or fortran(solver will have mathematical model for CFD equations). Now how do I connect the geometry file to my solver file so that my solver can understand the geometry and knows the condition of each point. solver knows that point A is next to point C, not point B because there is a solid boundary. Solver knows where the fluid should move and what all point are in a particular section. Then how can I export all the data to visualise in paraview.

This might sound confusing but i'll tell what I am not referring to.

I know openfoam is there for these things but I want do everything on my own. Basically I want to make a geometry, generate mesh for meshed methods, run my custom made solver which is a file of computer code in c++ fortran or julia, then output the results in paraview format, and verify the solver with results.

I have made a single file to solve INS equations with fraction step method, but that whole code was able to calculate flow field in a square grid only. I want to make a solver which is more general, so I can use any geometry with one solver file. but I always get stuck with how can I connect my solver file with a custom and more irregular geometry. I can also generate a mesh file with gmesh or salome but still how do I make my solver code to understand that mesh file.

Above I talked about geometry directly because I was more focusing towards SPH method, so I am not sure generating a mesh would me good enough.

I tried searching on internet a lot but nothing comes up.

Again, I don't want to use the already made software packages, but want to create my own. I can deal with some tweaking of my solver code for different geometries but don't want to change whole program.

This post is very long and I guess that answer might also be longer than this. So, it would be really great if someone can suggest a book or internet source where i can find this information.

[sbaffini]

I'll try to be as complete as possible, but I want to highlight that you aren't properly in the optimal position to embark into this journey. Where you stand, indeed, seems to be the beginning of the journey, where you start learning and understanding what you need in order to achieve what you want. However, that's where we all started, so take this as your first step, not as a reason to give up.

Now, in order to proceed from where you stand, you really need to be clear about what you want to achieve, as you mentioned two very different approaches to the computation of fluid flows.

Let's first consider SPH, as you mentioned that explicitly. I am no expert in it, but the general idea is (or should be) that your equations describe the spatio/temporal evolution of particles. Particles can interact between themselves and boundaries, and both interactions are described by certain integrals with some kernel functions.

Neglecting parallel aspects, what you need for SPH then is an initial distribution of particles, a way for each particle to know its neighbor particles (i.e., close enough to be within the radius of the integration kernel), a way for each particle to know when a boundary is within its kernel radius and a way to discretize the integral over the boundary when it is within the kernel. I'm pretty sure that a triangulated boundary is what most SPH code use, but I have no idea how such integrals are discretized. I see that ghost particles (mirrored on the other side of the boundary) might be a choice, so knowing the closest boundary point to a particle and the normal to it might be needed (to correctly place the ghost particle). So, in the end, you need a way, for each particle, to know the triangles and points (i.e., other particles) within a certain distance from it. Thus, while the method is certainly a meshless one, in the end, you might practically need an underlying support grid to make these geometric searches. This also implies that, while there is no absolute formal requirement, you will also practically need a domain where your searches will be limited, as well as a specification for what happens if a particle wants to cross it for some reason; so, in the end, you will specify boundary conditions on it as well (unless you are sure that your STL surfaces define their own closed domain and no particle is present outside of it).

As there are no meshes properly involved, there is no grid generator involved, just STL surfaces and a domain, so I'm pretty sure there is no standard way to handle boundaries on files in these sort of codes. Roughly speaking, you will just need a way to write on file a boundary condition you want to be associated for each domain and STL boundary. Basically, everyone chooses its own format here. Summing up, you will need a files that specifies a domain, the STL files, boundary conditions for each domain and STL boundary and, finally, intial particle distribution and associated fields. This latter file can probably be in the same format to restart a simulation that was already launched before.

[devansh.purohit]

Thanks for your reply. It is really informative. I know I have a very long way to go but your post did gave me a clarity. I guess I will read more in depth about SPH method and try to understand it by first solving simple problems and then getting into more complex versions.
But thanks again for the help

[sbaffini]

Whe you consider instead more classical approaches (considering your goal, I will assume unstructured celle centered Finite Volume), there are several differences to be considered.

First of all, between the geometry and the solver there is a need for a mesh generator. Mesh generators will take your geometry description and your specification of mesh size distribution and produce a mesh out of it. In case of an STL input, you will also need to specify a domain (unless, again, your STL surfaces define a completely closed spatial region), but not all mesh generators are happy with STL files as input; some require nurbs surfaces (STEP, IGES, etc.) and that a volume entity can be built on them to be meshed.

The mesh generator will eventually write the mesh to a file and, independently from the specific format, this file will have a section dedicated to boundary faces (i.e., the boundary faces of those cells that end up next to your geometric boundaries). The mesh generator typically has a mechanism to allow the user to group the geometric input surfaces according to the required set of surfaces requiring different boundary conditions, so that they will end up in different lists in the mesh file.

As the mesh generator kind of lives for itself, it has sense to take it quite separate from the solver, so in the end it doesn't do typically much more than this. One solver could specify boundary conditions in a way different from another solver, so this is typically handled at the solver level. Still, mesh generators can write the mesh in different formats that are understood by different solvers. In any case, there is a minimum required set of information for an unstructured grid of a FV code that is common to every solver.

Then, your solver will need to read the mesh file produced by the mesh generator and store all the required information, which is basically everything for unstructured grids.

Finally, a FV solver will have lists of cells with different properties and of faces with different boundary conditions or internal (including neighbor cells). These information will have to be integrated by the user trough the solver, in a way or another, while knowing the geometry/mesh (i.e., you need to know how many boundary conditions and materials are needed). In the computation phase, the solver will compute fluxes on faces and source terms in cells to eventually advance the solution to the next iteration or time step. Fluxes and source terms will obviously depend from the geometry of the mesh, but are otherwise the same stuff handled in any structured FV code. Obviously, the coding for unstructured grids requires a reasoning which is completely different from the i, j, k indexing and is fully based on the lists mentioned above.

[devansh.purohit]

thanks again
it seems quite an amount of work. I guess that is why mostly people go with openfoam solver and modify them for specific case.
Sbaffini, all the things you have told me are really helpful so thanks again for this. I will start more work from my side to learn these concepts.