PicoGK and Simulation #32
Replies: 2 comments 2 replies
-
Hi Josefine, thanks for the simulation feature. This is what I was looking for and will be trying with my work here to have LBM coupled with the geometry. Next, I will be trying to find those voxels that has velocity magnitude less than certain amount which I would like to remove it from the geometry. I have few other things in my mind as well so will be working on this more. I downloaded it and was trying to apply the code, I believe the |
Beta Was this translation helpful? Give feedback.
-
Hi Jigar, these classes are part of PicoGK, and are included as submodule in the Github repo. If you downloaded it via the ZIP, you have to copy PicoGK from your PicoGK installation. If you are cloning the repo, make sure you init all the submodules. Lin |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, everyone!
I am opening up this discussion, since we are receiving many questions about how PicoGK can be integrated with simulation tools. With PicoGK v1.6 we enabled access to VDB metadata, vector and scalar fields (in addition to just voxelfields). We see a very elegant, possible solution in using one single VDB file to encode all data that is needed for a simulation. I have published a first attempt here:
https://github.com/leap71/PicoGK_SimulationExample
It is an example project showing how all necessary information for a simple fluid flow simulation can be written and read from one VDB file, that includes fluid and solid domain as voxelfields, the fluid density and viscosity distribution as scalar fields and the initial state of the fluid velocity (this includes inlet boundary patch as you would do it traditionally) as a vector field.
At this stage we are looking for people with knowledge in the field of simulation, ideally you are developing your own tool, to give us constructive feedback. We are aware of the fact that this is not following the traditional approach with volumetric meshing and boundary surface patches. A voxel-based approach obviously tailors better to simulation methods that run on regular grids like the Lattice-Boltzmann methods. However, from a Computational Engineering perspective, the geometry of an object and its physical behavior should not be two completely separate things. CEMs have a lot of metadata about physical constraints anyway, so driving an automated simulation setup would be rather natural, without the need for someone to manually click and re-assign boundary conditions...
Please check it out!
As a teaser: A mesh deformation preview of one of our rover wheels.
Beta Was this translation helpful? Give feedback.
All reactions