pressure disagreement in water tank
Dear all,
I encounter a problem about water pressure and still cannot find an answer. I am appreciate if anyone can give me any suggestion of idea.
The case is very simple. I set a 2D rectangle wave tank with steady water. No extra force expect gravity. Initially, the pressure distribution along the water height agrees with static water.
I run the code to the equilibrium of particle distribution. And I find at the end of the computation the pressure/Rhop distribution along the water height is quite different with theoretical result.
Where is the problem? Is it related to the tait's EOS? Thanks.
I encounter a problem about water pressure and still cannot find an answer. I am appreciate if anyone can give me any suggestion of idea.
The case is very simple. I set a 2D rectangle wave tank with steady water. No extra force expect gravity. Initially, the pressure distribution along the water height agrees with static water.
I run the code to the equilibrium of particle distribution. And I find at the end of the computation the pressure/Rhop distribution along the water height is quite different with theoretical result.
Where is the problem? Is it related to the tait's EOS? Thanks.
Comments
I carried out same numerical experiment.
This is how I see the problem.
One aspect of the issue is particle inconsistency so the particle sum of pressure forces isn't equal to gravitational force (especially near the free surface). This causes compression of the fluid so fluid column starts to oscillate (numerical stability problem).
Also, in original DualSPHysics code, initial pressure distribution is hydrostatic (p=rho0*g*h) but density distribution is not (rho is not equal to rho0). dp=rho*dz*g (for compressible fluid). dp=rho0*dz*g (for incompressible fluids).
I hope I am not wrong.
All the best.
First of all I should be grateful for the codes.
I have the same problem and I couldn't get hydrostatic pressures in a 2D tank without any external forces after running the code.
Actually we can see all particles start to oscillate in the tank or start to compression(Level of water goes down in the tank)in it!!
I appreciate if anyone could help me in this problem.
Thanks again for your helps.
Regards.
I solved the problem by introducing gravity acceleration in a kernel summation (to compensate particle inconsistence) but this solution can be applied on this problem only (in other problems, this correction would be reduce wave celerity). Of course, making this change require changing source code.
Also, you could dump oscillation by increasing artificial viscosity coeff.
Of course, solution might be trivial-you could set speed of each particle to zero:-).
Regards.
Thanks for your solutions.
I'll test it in my model.
Regards.
I solved this problem in another way and have got a ideal result as presented in "A comparative study of truly incompressible and weakly"(http://onlinelibrary.wiley.com/doi/10.1002/fld.3824/abstract)
In my test, the most import change is 2 times the B in Tait's equation of state before putting xxx.xml into the dualsphics.exe. This change makes pressure reasonable. But it doesn't work if one times coefsound by sqrt(2). Hoping you guys can tell me why from the code.
I also set the number step of shepard density filter as 70, which will make the density/pressure steeply with the depth and more closely to the hydrostatic pressure distribution.
If I understood correctly you are doubling the B in the xml file, is that right?
That is, the file out of the gencase.
DualSphysics calculates the numerical speed of sound Cs0 from your constant B.
The order is:-
gencase uses the density rhop0 and the height of the fluid to calculate the maximum potential (vel x multiplier) for the numerical speed of sound at the gencase only.
Since the b is calculated and stored in the xml file, the DualSPHysics Cs0 comes directly form the B parameter (see JSph.cpp).
Thus, if you double the B parameter in the xml, the Cs0 will change in DualSPhysics without you modifying it.
But the *.bi2 you are feeding to DualSPHysics uses the old Cs0/B. In the first time step the new parameters adjust the pressure to the new B.
Therefore you have increased your Cs0 and made your simulation "less compressible". I would advice you reduce the Shepard filter to around 30-40 since you have increased the Cs0 a lot. Also your computational time will increase since dt is a function of Cs0.
Thanks,
George
Thanks for all you participation and suggestion. I see my last trick that using 2 times B for Tait's EOS after gencase.exe is difficult to explain why it comes to a good results. Maybe it just a coincident for this case.
I have found another way seems to be more reasonable to this problem. Hoping someone can join and ensure my proposal.
The particle oscillation is due to the unbalance forces on it.
One problem is that the boundary density will be changed during the computation due to the dynamic boundary condition. But the boundary density is set to be RHOPZERO in the code initially. This treatment causes a discontinuity of density/pressure near the place where the fluid particle is close to the boundary. I think it plays an important role in oscillation. I add a function to initial boundary particle density according to hydrostatic pressure.
Another thing I noticed is that if the boundary particle distribution is set to stagger pattern as suggested. As the computation processed, the fluid particle is going to be distributed as stagger pattern. I think it is close to the equilibrium. Thus, I set the both boundary and fluid particle lattice to be stagger pattern.
After both treatment, it seems to work good. But one thing still puzzles me is that the boundary density at some point is unphysical. For example, the point density which is close to the fluild and air interface is very high.
Additionally, to gfourtakas, I don't understand about the relationship between the Shepard filter applying step number and compressibility. Would you please
explain more? Thanks a lot.
best,
Sukun
I had the same problem. the problem is with the dynamic boundary conditions. Since we set the particles in a fixed table order and not by the hydrostatic pressure distribution. The particle wants to reorder themselves according to compressiblity. They settle, but they hit the hard rock of the dynamic boundary particles. The force created between the fluid and dynamic boundary particles generate a pressure wave which moves inside the fluid. These pressure waves travel inside the fluid and keep on reflecting from other edges and free surface.
the best solution is to use "Periodic Open Boundaries" when you have "mirrored" boundaries such as two vertical sides of the tank.
Using more frequent spatial filters like 5 for Shepard filters or more artificial viscosity are another ways to damp these waves, but as my experience, they just smoothen the pressure wave edges and can not get rid of them completely.
Cheers,
Jalal.
I have found that pressure disagreement in the water tank is not just due to the boundary condition."kernal function truncation near water surface" cause unreliable pressure field on the surface.
As Jalal and others said boundary particles are set in fixed positions without hydrostatic pressure distribution.This discontinuity of density and pressure near bottom of tank makes pressure oscillation.
In v.3 by implementing Delta-SPH instead of Shepard filter these oscillations near boundaries will disappear(without using artificial viscosity). Actually if we use only the Shepard filter, I have seen that by increasing the max time of simulation, this density filter can not overcome the pressure oscillations and we can still see the disagreement for pressure parameter near water surface and the bottom of the tank.
If there was a way too just implement KGC for surface particles (correcting kernal gradient functions when its influence domain truncated) I think pressure field for water surface particles will be remain zero.
For eliminating the pressure oscillation near boundaries we should change the boundary condition and the way we could define boundary particles. As its said in the new manual, a new boundary condition will be added to the next versions.
Cheers,
Mojtaba
The code MeasureTool that you use to compute pressures include a kernel correction to avoid these problems...
you must play with parameters:
- kclimit
- kcusedummy
- ...
These corrections in MeasureTool are just implemented on the output of the DualSPHysics.exe and they are not involved in solving the hydrodynamics equations like momentum. Therefore I think correcting "just the results" of the SPH equations couldn't be acceptable because we have neglected the effects of these corrections (changing forces in boundary and free surface) in our hydrodynamics calculations.
Thanks for your consideration.
Regards,
Mojtaba.
On the other hand, we have the problem of consistency and kernel truncation error near boundaries. We are now working on new BC's, those similar to virtual boundary particles that "fill" or "complete" the kernel area and other type based on boundary integrals where kernel correction is included.
Regards