RBF script

[DanW97]

Hi,

I saw that stl files can be represented via rbf in the sharp solver, and that a script to generate them in the required format would be provided in the future. I was just wondering if there were any updates on that? It would be really cool to use the sharp solver with more complex objects such as impellers!

Cheers,

Dan

[Luckabarbeau]

Hi Dan,
Yeah, this feature is still in development but should be done shortly. @oguevremont is the leading developer of this feature; I think he will be the best person to answer where we are at on the development of this feature. However, I believe that at the moment, it is possible to generate a sample impeller (e.g., Rushton, PBT) by a composite of sample shapes already implemented in the sharp IB solver (this has not yet been extensively tested).
Again thanks for your interest,
Cheers,
Lucka

[DanW97]

I can give that a go, the impeller I want to play with is a touch more complex than adding some primitives together, but I think I could get somewhat close to the actual shape of it. Would I be able to specify the shapes in a particle subsection (so i can set the motion properly), and also include spheres in a particles file for the simulation, or are the two particle insertion methods mutually exclusive?

Cheers,

Dan

[Luckabarbeau]

I just did some tests.
They are mutually exclusive at the moment since the position and velocity of the impeller parts must be specified as functions that are not yet possible in the particle loading file. Also, if you are interested in the interaction of the particles with the impeller, we don't handle contact with non-spherical objects. However, sphere contact with non-spherical objects could be implemented quickly.
Also, the other problem you would encounter is that the particle integration (coupling with the fluid) and the use of a function ( impeller motion ) are mutually exclusive in the code. This would be fixable with the simple addition of a parameter and if statement in the object integration function.
Also in the tests run this morning to create an impeller by a composite of primitives, I encounter two issues.
First, the reference for the orientation of the object seems to have a sign error ( the orientation is flip)
Second, the force and torque evaluation on the faces of primitives in contact is wrong since the code evaluates the force from the flow inside the other object, which is not physical.
All these issues are fixable. It is just a matter of finding the time.
The flow result looks good, though :)

Cheers,

Lucka

[DanW97]

How much work would those fixes be? My C++ and FEM isn't fantastic but the source code is really well written so I should be able to pick up what I need to do, if I am pointed in the right direction :)

Cheers,

Dan

[oguevremont]

Hello @DanW97,
Thanks for your interest. The script to generate RBF from STL files is still in development, but a functional version is available on this fork from bitpit. The script is /examples/levelsetRBF_prototype and there is a README that should help with its usage; feedback regarding its usability and performance are welcome. The resulting .input can be placed next to the .prm used by Lethe.

The torques and forces evaluation should be correct when using RBF shapes since there are not overlaps between component shapes (unlike composites). The orientation flip will be fixed soon.

Regarding composite shapes, it isn't possible yet to declare them in the parameter file directly, but it will be added. In general, using composite shapes should be faster than using RBF shapes because these require looping over multiple nodes to compute the distance value, so when it will be available the composite option should be considered for "simple" shapes.

Regards
Olivier

[DanW97]

Hi Olivier,

I gave the script a go, I'm a bit concerned that it took ~16GB of memory to convert a 5mm sphere (~300 triangles in the stl file) into an RBF with the following parameters:

nb_subdivision nb_adaptions radius_ratio base_function mesh_range max_num_threads
16 0 0.1 2 0.1 1

Am i simply putting in wrong parameters?

Cheers,

Dan

[DanW97]

Btw, if you get different memory usage, can you tell me what version of PETSc you use?

I had a weird error with lethe that disappeared on recompile where reading meshes made it request PB of memory. I changed versions of some deps during that, and since bitpit and lethe share a petsc dependency I'm wondering if something equally funky happened here

[oguevremont]

Hello Daniel,

I'm trying to reproduce your result but I don't reach 16Gb with your parameters. Using /usr/bin/time -v, the Maximum resident set size is around 7Gb, although I don't see the system monitor curve reaching that high. I'm unsure why it even reaches 7Gb, but it doesn't really increase when we refine the RBF to a certain extent (nb_subdivisions at 32 or 64).

The PETSc version I use with bitpit is 3.17.4, but the version I use for Lethe and deal.II is 3.13.1.

If you'd like to send me your files I can try them on my computer. The only parameter I'm unsure from yours is the radius ratio at 0.1; I often take 1, since it means that the nodes "barely" see the first neigboring nodes and there is no coverage hole in the domain. I'm unsure what the effects of 0.1 are.

[DanW97]

Ah, I used 3.18. I'll give 3.17 a try and see what the memory usage is like there. As for the stl file it was basically gmsh default settings meshing a 5mm sphere, so nothing too fancy.

Cheers,

Dan

[Luckabarbeau]

Hi @DanW97,

Recently @oguevremont and I added the composite shape to the sharp IB solver, which allows us to model complex geometry relatively easily in the sharp IB. It works by allowing you to define a shape by the composition of primitive shapes with boolean operations (at the moment only union and difference). There is no example as of yet. We are currently working on that. In the meantime, I joint here a reproduction of example 11. In this version of the example, we modify the top boundary to a weak no-slip because sharp IB particles in motion require at least one open boundary or one weakly imposed boundary. Since we don't have a weak slip boundary, I used a weak no-slip boundary.

Here is example 11 with sharp:
mixer_sharp.zip

Note: to visualize the geometry in the sharp solver, you need to use the contour tool of ParaView on levelset output field and set the Isosurface to 0.

Hope it helps and can be helpful to you

Lucka

[DanW97]

Hi @Luckabarbeau,

That makes sense, most of what I am interested in usually involves systems with a "free" surface, so having a weak condition on the surface is no issue! As for contact with a composite shape and spheres, would the routine be similar to how Lethe-DEM handles floating meshes and spheres, i.e. I could adapt it, or are there fundamental differences in how a floating mesh and a composite sharp particle appear under the hood that would mean the implementation is very different?

Cheers,

Dan

[Luckabarbeau]

Sadly there is an important difference between how composite shapes are defined and how floating meshes are defined. Shapes are defined as a sign distance function, and floating meshes are defined by a triangular mesh. Most sign distance functions implemented are exact (the only exception is the helix which is exact only near the surface). But the composition of shapes with union and difference are not always exact (see this link for a relatively simple explanation of why this is the case). These operations guarantee to preserve only the surface of the object. Although, shapes defined by a union are exact outside of the shape, which allows us to use the sign distance function to calculate contact forces. This is not the case for composite shapes with differences.

At the moment, contact between particles and composite shapes defined only with unions could be relatively easily implemented since it would follow a similar workflow to normal particle-particle contact. But generalizing it to shape defined with differences as well would require a bit more work to find the contact point between the two shapes. Also, this kind of contact algorithm could be extremely computationally heavy since the sign distance function of a complex object can be relatively expensive to evaluate. We would have to try.

I think defining a floating mesh of the impeller identical to the composite shape would be simpler to implement since we could reuse all the existing functions for floating meshes, and it would be more generalizable. But this would make cases messier since you would have to define the impeller and its motion in two different ways.

Cheers,

Lucka

[DanW97]

It would be too easy if SDFs worked as nicely as triangles do I guess 😁

Regarding the floating mesh idea, I guess for now I could write a python script that runs the dem and sharp solvers in lockstep (for every sharp step, run coupling_frequency dem steps), making heavy use of restarts. It won't be super quick, I know but it seems like it would work.

I think in the interim, having a dual object setup could be sane, allowing the sharp solver to read the dem subsections. To help keep the duplication down to a minimum, would it make sense to add a parameter that copies the motion/orientation settings into the floating mesh functions so that both objects are synced up? If this sounds like something that'll be useful, I can try and work on adding it in?

Cheers,

Dan

[Luckabarbeau]

Adding a new contact force with floating mesh would be the best course of action in the short term. It would be significantly faster than restarting, and it would preserve all the solver's characteristics (stability). You would have to define the impeller twice, but that wouldn't be that big of an issue. Otherwise, if your impeller doesn't need the difference operator (e.g. PBT). I would go with the even simpler solution of adding a contact force with composite shapes and spheres. If that is something you would be interested in, I would be happy to help you do it.

Cheers,

Lucka

[DanW97]

Yeah that sounds sensible to add, I don't work with any impellers that would require a difference operation so that'd work for me, I wasn't sure how generalisable it would be to include difference as well -> whether it's simply more lines to ensure the shape is treated properly or if the approach is in fact entirely different.

It's definitely something that I'm interested in!

Cheers,

Dan