Question about Inlet and Moving Walls


I am looking at the FlowCylinder example in "inletoutlet" and I see that the walls have been giving a motion:

Why is this the case? In the other files (for an example OpenChannel) does not have any movement of the wall/ground. Can anyone explain why is this the case and when it is important to have movement of the wall?

Kind regards


  • To my understanding, if the walls were stationary then we would have greater velocity gradients which would effect the flow field around the cylinder. Boundary layer might interfere with the flow field.

    By giving a motion to the walls, we’re mimicking an infinite domain and hence the boundary layer interference is reduced.

  • @circles okay that makes sense kind off, since we would have that the fluid flow at the edge (wall) would be equal to the fluid inlet flow just in opposite direction, so the relative velocity between the two is zero, I assume?

    I've got two further questions:

    1) Can you explain to me why the moving wall in FlowCylinder does not leave the boundary? Is this motion some kind of new feature where it is "pseudo-velocity", or did I misunderstand something?

    2) Why is it bad to have high velocity gradients at the walls? Usually we would have these anyways, what makes it particularly bad in SPH?

    Kind regards,

  • Hi,

    1) Periodic boundary conditions are activated in the flow direction, so the two walls are made up of periodic DBC.

    2) It is bad when your domain is not very large, since (depending on the Reynolds number) the boundary layer may increase in size to an extent where it affects the flow accelerating around the cylinder, or the low pressure wake behind it. Also, it is not good to have large gradients near the open boundaries, as the simulation usually becomes unstable.

    Ideally you would need open boundary conditions for any domain edge in flow past a cylinder, but the way the current OBC are implemented does not allow to manipulating tangential velocities/changes in position of particles. Thus this is just a numerical trick to make the simulation work in a small computational domain.

    I believe coding of features such as free-slip and no-slip boundary conditions based on the OBC algorithm currently present in DualSPHysics is under implementation, and would provide an alternative to the set up in this test case.


  • Thanks @taffo ! Your explanation have made it easier to grasp, especially for 2), but now I have so many questions more related to 1) , so here goes.. :-)

    Thanks for pointing out the use of periodic, I did not see it earlier. I am bit confused though since we are already employ an inlet/outlet scheme for the fluid particles? So the fluid particles are also experiencing periodic behaviour, ie. being re-entered with prescribed (or old?) velocities?

    Secondly I just saw this (marked with yellow):

    Could you explain to me, how come the inlet has direction of "right", while outlet, has direction of "left" - this seems a bit counter-intuitive for me, the flow will always move towards the right?

    Kind regards

  • I believe the direction specifies where the buffer layers sits relative to the flow domain.

    For example, inlet buffer layer is on the left end of the domain hence the fluid particles(in the main flow domain) is to the right of the inlet. Outlet buffer is on the right end on the domain so the fluid particles are located on the left end of the outlet buffer layer.

  • edited July 4

    The direction "right" or "left" is used to create the ghost nodes. For an inlet with flow going from left to right, you want your ghost nodes placed in the fluid, therefore placed to the right of the buffer. Similarly (but with opposite sign) for the outlet.

    Buffer particles are NOT experiencing periodic behavior, particles are created and destroyed within the buffers, whereas if you look closely, moving walls extend a bit farther than the buffer areas, and experience periodic behavior.

    We will create a XML guide soon where all these questions will be answered more in detail.

    In the meantime, you can have a look at this presentation I gave at the DS workshop in Lisbon:


  • Thanks @taffo ! This helps a lot, will read through it before asking any more questions.

    Kind regards

  • @taffo in the example of the 07_CurrentHull, would you mind explaining this part to me. The flow is very obviously moving this way:

    But in the XML it says:

    So inlet has a fixed velocity of 1.5 m/s in postive x-direction, no problem there makes perfect sense. But out has a fixed velocity of -1.5 m/s in the x-direction? Why is it so, does it have something to do once again with which side fluid is on? For the inlet the fluid is to the right, for the outlet it is to the left ie. I hope you could comment a bit on this, since it has really been bothering me :-)

    Kind regards

  • The zones are defined inlet our outlet depending on the properties we define later.

    On the other hand the zones are also first defined using direction "left", "top", "bottom", "right", "front", "back".

    In this case mkfluid=1 has direction "right" since the fluid is on the right hand, and mkfluid=2 has direction "left" since the fluid is on the left hand.

    Later, with "imposevelocity" any POSITIVE value means in the direction "looking" to the fluid so that creates an INLET condition, but if you use NEGATIVE velocity then you are creating an OUTLET condition.


    We are going to release a more complete XML_Guide.pdf with detailed description of inlet&outlet parameters soon

  • @Alex thanks!

    It makes total sense now, I feel a bit stupid, but atleast I've learned it now :-)

    Yeah, don't be too stressed regarding documentation, in the end learning is done best by trial and error and hopefully you can get an idea of what can be difficult for us externals to grasp. Thanks for your effort.

    Kind regards

  • We release inlet&outlet too soon without more complete examples and documentation... we have to improve this soon.


  • That is true Alex, but this was much better than having to wait half an year more. The alternative would have been to wait until every piece of documentation was done, but this is such a tiresome process and users would have to wait unreasonable amounts of time - there I believe it is better to tell people, "Hey guys, we've got this, a few examples, try to see how much you can figure out" and then the community will respond with how much they understood / were able to use it - rinse and repeat.

    Maybe we have to turn it into some kind of community effort, so that people who like to benefit others can do so.

    Kind regards

Sign In or Register to comment.