Normals for slightly complex surfaces MIGHT BE calculated wrongly


Working with testing new DualSPHysics beta capabilities, I have found that if one uses a slightly complex distribtution as:

The Cfg_Normals file shows wrongly calculated normals:

But svshapes command:

Does not show these artifacts - I am not sure what to trust, but going with svshapes for now. Also note that to actually perform the calculation it was necessary to use distanceh = 28 - since corner particles in this geometry is quite difficult to calculate for some reason.

Here I have not done anything crazy, simply just loaded a vtk file in, discretized using DualSPHysics normally and then done the normal calculation using xml directly.

Kind regards


  • Please note that v5_BETA only supports normals computation for simple geometries. We have not tested or tried any complex shapes so far.

    This is why the cases you are testing will not work.

    Normals may be computing but not used in the SPH execution.


  • Thanks for your fast response. When the simulation is done I will come back with my findings - to my understanding it should be using mDBC though, since that is what the run file informs me and all particles have normal values.

    Kind regards

  • The simulation is done now it seems like that mDBC was applied correctly

    No significant physical gap is observed between fluid and solid particles even at low resolution (ie. few particles).

    Kind regards

  • ummm interesting heheh

    Can you compare the same case but with DBC just to observe the differences?


  • @Alex I have done that now

    Orange is mDBC, blue is DBC. We see that orange particles are closer to the fixed black ones, especially in marked area. I therefore conclude it succesful.. at least from a visual inspection :-)

    Next step is to get my custom one to work..

    Kind regards

  • Thanks @Asalih3d

    For a better comparison can you plot them in different frames and... plot density values of all particles? fluid and boundary?

    That will definately show us the difference.


  • @Alex

    Sorry seems like I have lost DBC results (probably overwriting unfortunately), but I still have mDBC (which is the most interesting I assume), which shows that (dp = 0.05 timestep = 723):

    And note the range 1000 to 1001 kg/m3. So this looks very good. I have also done one with dp = 0.0125:

    So for mDBC it looks very good even for slightly more complex surfaces. Unfortuntaly the normal generation for this one took 2 hours, since I had to use distanceh = 156 to actually ensure every particle was assigned a normal, but it is beta so understandable.

    Kind regards

  • There is no need to assign normal vector to all the boundary particles you have created...

    Only those ones at distanceh=2 (or 3 if you want) are enough!!! What is important is to have the enough number of particles that guarantee the 2h distance from fluid to interact with.

    So that 2h <= x*dp, where x is number of layers”


  • I see thanks for noting it. Unfortunately the particles who were not assigned normals were at the upper surface / layer so ie. right next to the fluid and always at the "corners". So I had to make sure that these are included.

    Kind regards

  • To further explain what I mean with corners have a look at a wave tank using regular particle distribution:

    Blue particles show particles with NO assigned normals - this in the upper layer (i.e. first contact layer with fluid) and therefore important that it is there. Increasing distanceh to even 100 has not helped in this case, even though the resolution is dp = 0.05. Seems like mDBC is not yet suitable for regular particle distributions and only work with preassigned freedraw mode or completely straight lines / corners etc. From analyzing normals I see that:

    The blue particles in the first picture with no assigned normals means they get horizontal normals (look at the horizontal blue lines).

    This is to help with further debugging / optimizing. If anybody can get this to work I would ofc gladly hear back.

    Kind regards

Sign In or Register to comment.