Wall attachment and the "gap" issue

Hi,

I'm running a simulation case where water is poured on boxes which are standing on perforated racks (see figure). There are three racks, but only two have boxes. I have some questions.

1) In the simulation, the water falls off the edge of the boxes like a waterfall (e.g. to the right in the figure). In reality, the water pours down the side of the boxes. Is there a way to properly capture this "wall attachment" behavior in the simulation?


2) As explained in the wiki, "the forces exerted by boundary particles create a small gap between them and the fluid particles (1.5 times h)." This effect is clearly visible when looking at the amount of water pouring through the holes at the bottom of each rack. Because the holes are small, most of the hole area is "blocked" due to the gap issue. I suspect that this results in the simulation underpredicting the flow through the holes. Is there a way to ensure correct flow through narrow gaps and apertures? Decreasing dp does not solve the problem as the effect is significant even at the smallest dp allowed by the simulation.

3) The rack is an stl file. It is included as follows:

<drawfilestl file="fileName.stl" />

It seems that Dual SPHysics requires the stl file to be in the same directory as the xml file with the case definition. I want to store it elsewhere, but if I try using a relative or absolute path, GENCASE crashes. The following would achieve what I want, but it does not work:

<drawfilestl file="../otherDir/fileName.stl" />

<drawfilestl file="/path/to/otherDir/fileName.stl" />

Is there a way to get GENCASE to accept relative and/or absolute paths as shown above? I'm running on Linux.

Thanks!

Comments

  • You have to use mDBC, DBC is not going to cut it for this.

    Kind regards

  • I had the same problem like you in 3). According to the video "03 DualSPHysics XML: How to Insert STL file" on YouTube it should work the way you did it, just with backslashes instead of slashes. For me it didn't work with slashes anyways tho. I just switched to linux and it worked exactly the way you suggested.

  • Also @Asalih3d , what's the difference between mDBC and DBC exactly?

  • English A, Domínguez JM, Vacondio R, Crespo AJC, Stansby PK, Lind SJ, Chiapponi L, Gómez-Gesteira M. 2021. Modified dynamic boundary conditions (mDBC) for general purpose smoothed particle hydrodynamics (SPH): application to tank sloshing, dam break and fish pass problems. Computational Particle Mechanics. doi:10.1007/s40571-021-00403-3.


  • @Asalih3d

    I repeated the simulation with -mdbc. The log contains the following lines:

    Boundary="mDBC"

     SlipMode="DBC vel=0" 

     mDBC-Corrector=False

     mDBC-FastSingle=True

     mDBC-Threshold=0

    However, the problems remain (see figures). Are there some additional mDBC options that I should set?


    @Zwulch

    You are correct, it does work with both relative and absolute paths. GENCASE prints e.g.

    File '../otherDir/fileName.stl' could not be copied.

    which I took to be an error, but upon testing the simulation runs fine anyway. The only difference, as GENCASE tried to tell me, is that the stl file isn't copied to the output directory.

  • Using mDBC flag is simply not enough as far as I know. You should also put some effort into generating normals from the STL and ensuring that they point the right direction. Something is clearly wrong when you have large holes with very thin streams passing through them. I think you need to go have a look at your particle representation to understand what I mean.

    Kind regards

  • If the file cannot be copied it can sometimes be due size bigger than 25 mb.

    Kind regards

  • I don't really understand what you mean with "generating normals from the STL" ? I have a similar problem like anders, trying to make my testcase more realistic but I also struggle with boundaries and fluid particle interaction even though I changed the boundary method to mDBC. I'm using a pretty small particle distance (dp=0,0005) but the particles still don't want to go between the teeth of my gear. I think we are doing the same mistake anders :D


  • @Asalih3d

    The cell normals are correctly oriented (i.e. pointing outward from the body). I have the following settings:

    <hdp value="2" comment="Alternative option to calculate the smoothing length (h=hdp*dp)" />

    <definition dp="0.0005" units_comment="metres (m)">

    So h = 1 mm which means the "gap" region is 1.5 mm. This is roughly consistent with what I observe when looking closely at the 8 mm diameter holes (see figure).

    I tried changing the smoothing length by setting hdp = 0.5, but the results were completely unphysical. Can you explain a bit what you mean by having a closer look at the particle representation?


    For the record, my biggest stl file is 11 MB.


    @Zwulch

    Indeed, it looks like we have the same problem!

  • I need you to upload that picture, but with the particles of the structure instead of the mesh. As you know, the numerical method only sees particles, what you are showing here is the mesh.

    Your particles should then have normals "touching" the stl, as shown in the mDBC documentation. Right now it looks like that your particles lie on the edge of the circle in your picture and then it has a normal pointing outwards. To visualize in paint it should bel ike this:

    Where green is a correct normal, the red one is either too short or too long.

    So you are right it should point outwards of the body! BUT NOT, further than the mesh file, which it seems to look like in your pictures.

    Kind regards

  • Hey, do you mean this? That's how the normals for the case of my gears look like, exactly on the edge of the stl's like you suspected. Is there a way to configure the normals of the stl's manually?


  • Not as of yet, a solution is to use two stl, one for particle distribution, one for normals.

    Remember to use glyph filter to plot normals.

  • I found a solution today using two stl's and the mDBC example 04_dambreak, thanks for your help!

Sign In or Register to comment.