Being new to GPUSPH, I’ve been focusing on the provided example test cases, specifically the “WaveTank”. To measure my system performance and capabilities, I ran a bunch of test cases while decreasing the inter-particle spacing. From my past experience with Eulerian based models, I assumed this would be analogous to a grid convergence test. I don’t know the depths of GPUSPH’s numerical framework so I don’t know if my assumption is valid.
Attached you will find a time-series plot from two different gauges, where the different line colors correspond to different inter-particle spacing. One of the gauges is near the wave maker, the other is down stream. The main thing I want to focus on in this question is why do all cases appear to deviate from the initial still water level before the wave reaches the gauge? Why does the smallest inter-particle spacing (0.005) case show a significant drop in surface elevation as compared to the other test cases?
I did not change anything else in each case. The only thing I changed was the inter-particle spacing. After studying the plots and watching the animations, it seems that something is wrong with the initial conditions. The time-series should ideally be flat with an elevation reflecting the still water level. Only after the wave reaches the gauge should the gauge time-series start to change. I also noticed in the animation, the particles seem to be distributed in vertical layers over the domain, in which they “fall into place” after the first time step? It’s hard for me to tell, because I don’t fully know how the initialization works.
Can someone please help me understand what is going on and how I can correct it? Again, I would expect to see the gauge time-series converge and reflect the still water level until the wave hits the gauge.
EDIT:
As far as model parameters…looking specifically at the “WaveTank” source code, I think the still water level is defined by the parameter H = 0.45. Again, no other parameters are changed in the source code and the time step is adaptive.
Hello @GWAVE, this issue may be related to the filling of the tank, that with version 5.0 might be irregular for some inter-particle spacings. We have recently upgraded the WaveTank problem with some improvements that include the fix for this issue. This will be officially released with the new GPUSPH versions, but meanwhile, you can already use it by checking out the branch ‘next’ form the GPUSPH repository. We are also working on an SPH formulation that will prevent the waves to decay as they travel over the tank, which will be hopefully ready for the next GPUSPH release.
Thanks @vito.zago for your reply. It sounds like you’ve confirmed my suspicion…the initial conditions, i.e. filling of the tank, is at fault.
Over the last few days, I’ve been trying to utilize the preprocessor, “Crixus”, to initialize the domain particle fill. I thought this approach might overcome the issue. (see Crixus still supported? for more on that topic).
I’m glad to hear that it’s a known issue and has been addressed in the future release. I know you said I can checkout the “next” branch, but do you know when the official release is scheduled for? I’m just curious. Also, are the fixes you mentioned in the “next” branch specific to the Wave Tank problem, or are they universal to all problem sets? How does this solution relate to initialization using the preprocessor “Crixus”?
Lastly, if you wouldn’t mind elaborating on how the filling of the tank has changed in the “next” branch, I would be grateful. I can see that there is now a single call to “addBox” vs a bunch of calls to “addRect” in a loop. Is it simply a change of which function is called or has there been further enhancements under the hood?
SIDE NOTE
I tried to include the cylinders with the Wave Tank experiment under the “next” branch and it removes all the water particles. I’m not really sure of the “issue/bug” procedure with the “next” branch so if you could pass on the word.
Hello @GWAVE, most of the improvements currently in next are specific to WaveTank; as you may have noticed, the setup was thoroughly restructured. There have also been some general fixes in the way some geometries are filled, and this will affect other problems as well. All of this work is completely unrelated to Crixus.
I’ve given a quick look at the cylinder effect in WaveTank, and the issue seems to be due to the origin shift triggered at line 83. Removing the conditional block should fix the disappearing water issue, but there are still a couple of issues with the cylinders intersecting the floor of the domain (too many boundary neighbors for fluid in the area).
Any update or feedback on this? I’ve found that the particle filling in the “next” branch really helps to improve the consistency of the initial conditions, however I’m still seeing some rather significant wave decay. I’m sure I could mess with the physical (or numerical) viscosity, but then I’m just blindly turning knobs without knowing enough about the theory for justification. Again, just asking for an update as this appears to be the last hurdle in my project application.
(The formulation doesn’t have anything to do with the “DUMMY_BOUNDARY” does it?)
Hello @GWAVE, we are working on it on a development branch and as soon as it will be ready to be used we will merge it on the branch next and we’ll let you know. Let me know if you need it sooner and we’ll find a way to share it with you. The improvement doesn’t involve the boundary conditions but is mainly kernel normalization.
