Inlet/Outlet: Density/Pressure Fluctuations
Hello!
I am trying to use inlet/outlet functionality to simulate a drag flow as shown in examples/mdbc/05_FlowCylinder. In general my experience is that at Reynolds = 200 I get a good comparison with drag coefficients from literature (as also documented in Re200.ods in same folder), but for example if I try Re = 2000 (by adding another zero after comma for visco value), then the drag force is 3 times less than what it should be.
I think this is due to the pressure/density not being stable throughout the simulation and over time the simulation destabilizes and pressure becomes high and uniform in the whole simulation field. I have already made the domain considerably larger.
Is this a defiency in the inlet/outlet model which cannot be resolved as of now?
Kind regards
Comments
@taffo may help here
Regards
Hi Ahmed,
Did you end up figuring this out?
I've had similar issues to yours. I'm trying to simulate flow that has the real kinematic viscosity of water (0.000001) for flow over a cylinder of D = 0.05 m.
I am interested in a minimum Re of ~9100. I couldn't understand why I was getting such strange force values with high fluctuations and when I back-calculated to get the drag coefficient it was never the theoretical ~1.2 value it should have been. For example, I ran it for a Reynolds number of 38100 (note: I added gravity, which was set to 0 by default in the example) and my drag coefficient was around 0.4, which is 3x less than 1.2 (similar to your findings?).
I often thought maybe I was missing something and I was supposed to alter another input somewhere that I wasn't familiar with to balance out the changing of viscosity (CFL or resolution for example), but I started looking into the literature, and the papers I've found almost always use very low Reynolds numbers, on the order of <1000 and sometimes even as low as <100. Even Tafuni et al. 2018's paper on these open boundary conditions applies a min. Re of 20 and a max. Re of 200:
The highest I was able to find in the literature was Re = 9500 (for the 2D cylinder problem) in Sun et al., 2018.
However, the point of this paper is to present a tensile instability control they implement by "switching the momentum equation to a non-conservative formulation in the unstable flow regions" in order to specifically address the instability/numerical cavitation. I don't think has been integrated into DualSPHysics although I'm not certain; I ask about it in a forum post about it a month ago but haven't heard anything about it.
I also personally had the issue that decreasing the initial particle spacing made the drag force decrease as well (and drag coeff.), but that may be a different subject altogether.
You mentioned that over time, your simulation destabilizes; what is the general trend in your force time series look like? At what simulation time typically did it become unstable? Also, out of curiosity did you leave the gravity set to 0?
Thank you,
Sandra
Hello
Yes gravity should be disabled, i.e. set to zero if it is a 2D simulation. If it is 3D I might still set it to zero, if my fluid flow compresses too much, but that would in reality be physically wrong (especially depending on diameter of tube).
If you have a fixed flow and geometry, consider using OpenFOAM/FVM, this is where this method is very well developed.
In DualSPHysics you cannot get good results for fixed flow as of now, since no-slip condition is not enabled yet and turbulence modelling is still at a basic level, in the sense that it is based on a paper which is ~20 years old now and that turbulence in general in SPH is lesser developed.
I also personally had the issue that decreasing the initial particle spacing made the drag force decrease as well (and drag coeff.), but that may be a different subject altogether.
Change of resolution of course leads to different results - this is why it is important to do a convergence check.
The simulation becomes unstable since inlet/outlet in DualSPHysics is quite new and cannot handle backflow physics fully right now - over time it will improve since the developers are really good and sharp on details, but it takes time when they are busy, so we should have understanding.
Kind regards
Thanks for your feedback!
And yes, absolutely understandable; the developers are tackling some very complicated and impressive problems :)
Best,
Sandra