CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > General Forums > Main CFD Forum

How do I connect a geometry to my solver

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   November 16, 2021, 05:25
Post How do I connect a geometry to my solver
  #1
New Member
 
Devansh Purohit
Join Date: Nov 2021
Posts: 3
Rep Power: 4
devansh.purohit is on a distinguished road
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.
devansh.purohit is offline   Reply With Quote

Old   November 16, 2021, 08:25
Default
  #2
Senior Member
 
sbaffini's Avatar
 
Paolo Lampitella
Join Date: Mar 2009
Location: Italy
Posts: 2,143
Blog Entries: 29
Rep Power: 38
sbaffini will become famous soon enoughsbaffini will become famous soon enough
Send a message via Skype™ to 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.
sbaffini is offline   Reply With Quote

Old   November 16, 2021, 08:47
Default
  #3
New Member
 
Devansh Purohit
Join Date: Nov 2021
Posts: 3
Rep Power: 4
devansh.purohit is on a distinguished road
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
devansh.purohit is offline   Reply With Quote

Old   November 16, 2021, 08:56
Default
  #4
Senior Member
 
sbaffini's Avatar
 
Paolo Lampitella
Join Date: Mar 2009
Location: Italy
Posts: 2,143
Blog Entries: 29
Rep Power: 38
sbaffini will become famous soon enoughsbaffini will become famous soon enough
Send a message via Skype™ to 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.
sbaffini is offline   Reply With Quote

Old   November 16, 2021, 09:51
Default
  #5
New Member
 
Devansh Purohit
Join Date: Nov 2021
Posts: 3
Rep Power: 4
devansh.purohit is on a distinguished road
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.
devansh.purohit is offline   Reply With Quote

Reply

Tags
geometry, geometry export, mesh, solver, solver linking

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
foam-extend-4.1 release hjasak OpenFOAM Announcements from Other Sources 19 July 16, 2021 06:02
Solver crashing when water reaches specific part of geometry Nosravi OpenFOAM Running, Solving & CFD 9 April 15, 2020 12:36
Simulation of Flow through Complex 3D Geometry EmersonKB CFX 5 July 2, 2009 09:17
Solver and geometry choose for drag coefficient calculation around circular cylinder at large Re lin OpenFOAM Running, Solving & CFD 3 April 16, 2009 11:50
vitual _ real deneb FLUENT 3 January 22, 2007 05:31


All times are GMT -4. The time now is 03:00.