Is it possible for a simulation to run without the need to specify a gravity constant? what steps would i need to take so that this kind of simulation is possible?
Sorry i was not sure how to delete the comment i thought my simulation was not running when i specified gravity as zero, it was another unrelated error.
Is there something else that needs to be changed beside the gravity line in the xml file? Each time that I set it to zero I recieve an error which says "Text: Constant 'B' can not be zero. (B=coefsound2*rho0*g*(h_SWL)/gamma is zero when h_SWL=0 (difference of heights in Z-direction)". Any help is appreciated. Thanks
What you are seeing is not a bug so much as a design decision borne from the purposes DualSPHysics was originally designed for.
Basically, when you set gravity equal to {0,0,0} (or in fact anything other than {value,value,-value}) in the XML that you then feed into GenCase, it creates a beta constant that cannot be zero in the context of the SPH simulation portion (i.e. DualSPHysics). Unfortunately there is currently no way around this quirk, though it may be addressed in a future release (this is not my area).
If you are happy with modifying code then you can quite easily set gravity equal to zero yourself in the source and compile your own version. Other than that I suggest picking a very small value for gravity such that its effects are minimal in your simulation, i.e. {0,0,-1e-6}.
Hope that's of some use and apologies to the developers if there is some misinformation in there!
Thank you SLongshaw. I've managed to get it running now in micro gravity conditions but I'm running into a problem with particles escaping through the boundaries. The more I reduce the gravity the larger the amount of particles that escape. Was wondering if anyone had suggestions on this. I've tried altering time step and rho without success.
There could be a number of reasons your particles are escaping. Typically this is due to your time-step being too high or there being a slight geometrical inconsistency in the "forcefield" generated by the boundary particles because of bad placement of a particle, or it could be something less obvious such as the smoothing length or perhaps you have simply managed to define a case the boundary condition can't handle!
So first thing to do is load the output created by GenCase into your visualization tool of choice andcheck things look sensible at the boundaries.
The next thing to do is try to decrease the time-step that your simulation is taking. You say you are altering the time-step, how are you doing this? The actual time-step used is dynamically calculated based on a number of stability conditions. These are controlled by various global properties of the simulation (such as current maximum accelerations) but can be affected by changing the speed of sound coefficient so that the value for "Cs0" is raised (you can check the value calculated in the output of DualSPHysics when you first run it) or by altering the CFL value. Higher values for Cs0 will decrease the time-step (and of course increase computational time) whilst lower values of the CFL value will do the same. These properties do more than just alter the time-step of course, but at a very basic level this is what they do.
Getting a stable simulation is a tuning process I'm afraid, much like any CFD problem.
Can I suggest (if you haven't already) that you have a good read through the documentation provided with DualSPHysics, both the DualSPHysics guide and the GenCase guide as both give good information regarding the meaning of all the different parameters.
By taking gravity zero, the "B" becomes very small in Tait equation. Thus the fluid becomes too compressible and particles can squeeze and escape from boundaries. I think you need to find some way around this. increasing speed of sound is an option but having it too high could also lead to some other unphysical behavior between particles.
Jalal is quite right, GenCase will produce a low value for "B" if you feed it very low values for gravity.
One potential solution for this is to do as you have been, allow GenCase to produce your input XML file, run the simulation once and make a note of the value for "Cs0" (speed of sound) that your parameters has produced, then correct the value of "B" in the XML file that GenCase produced.
You will find it towards the bottom of the file inside the tag. You can use the following to calculate a new value of B: (Cs0*Cs0*Rhop0)/Gamma. The problem with this is that using very low gravity, chances are you will also have a very low value for the speed of sound (likely the specific issue causing the particles to exit through the boundaries). So you may have to tweak the value of coefsound to a very high number in order to force things.
The problem here of course is that all of these values are in some way linked, with GenCase being designed to handle standard gravity scenarios only, so all of this amounts to hacking things.
Another solution is to take the source code and create your own copy of DualSPHysics in which you can define the value of Cs0 (and all associated variables such as correctly according to the (non gravitational) forces in your simulation.
Hopefully in the future this is something that GenCase will handle correctly.
I figure there are two ways of doing this. One being manipulating the variables of DualSPHysics to force the program to work for my case, as you stated above. The other, which i've been trying to work on for the past few days, would be to make g=0 with respect to the boundaries. I've set up a simple 2-D case of a fluid circle dropping in a fully closed off box. I've been trying to add motion to the box so that it drops with the same acceleration as gravity using ''. The problem I've been running into is DualSPHysics saying the boundary has gone outside of the working domain. To try to fix this I've increased the pointmin and pointmax numbers to allow room for the domain to "fall" but this seems to have no effect. I will pursue your suggestions but was wondering if you had any ideas as to what might be the cause of this problem.
When you set a value for pointmin and pointmax in your XML that you feed in to GenCase, this is taken to be a suggestion for GenCase to use. Therefore GenCase then cuts your workspace down to what is actually needed.
The reason for this is that particle methods like SPH need a way of determining forces of neighboring particles (i.e. those within the smoothing length), to do this quickly the space is partitioned sing a grid-like structure. If you work on the premise that the potential simulation space is infinite (within the confines of single precision floating point) then you need an infinite amount of memory to divide the area, clearly not practical!
To avoid this it is desirable to keep static boundaries static, or at least ensure they remain within a definable area (i.e. a rotor spinning around an axis for example), therefore ensuring that the fluid particles also remain within this area.
Hopefully you can see why what you are trying to do doesn't work with DualSPHysics (or in fact any well engineered SPH code).
Really the best solution for you would be to download the source code and in there over-ride the value for "cs0" (speed of sound) and "b" so that they work for the accelerations in your system. Alternatively you could wait for the next release of DualSPHysics which I suspect will incorporate a number of solutions to your problem.
I am trying to understand how to remove gravity as well in my test case. Did anyone manage to do that?
In the simulation I am running, the fluid forces should only be due to the pressure gradient and viscous term, no body forces. I have tried to use very small gravity values as well as correcting the value of B, but that did not work. Any other suggestion?
A solution that I found while working on a zero g case was to scale the whole simulation up so that my acceleration due to gravity was equivalent to 1*e-6 m/s^2. The issue that I found in using dualsphysics for this is the lack of surface tension and wetting effects.
Thank you kfield! What I have tried so far is to find an optimum for the lowest value of gravity that I can use while avoiding weird behavior of fluid particles due to lack of surface tension and viscous effects...unfortunately I need to keep the (very small) scale of my problem fixed, because its physics would change otherwise.
Hi All, I just wanted to add a small comment regarding this... What Kfield said is very true, surface tension and possibly wetting would play a significant role in micro-gravity flows, so the basic WCSPH formulation would not fully incorporate the correct physics.
I also suspect the dynamic boundary conditions (only ones currently implemented) are just not suitable for such cases, as the noise in the pressure field generated by the boundaries without gravity to hold it down would become quite unstable, and several parameters (like B, Cs0 and artificial viscosity) would have to be tweaked just to get no penetration and stable results.
I have MUCH higher hopes for the delta-SPH formulation which should be introduced in version 3, to which you would still have to include at the very least surface tension to get realistic micro gravity flows.
Remove from the momentum conservation equation in a continuum fieldis the gravitational acceleration.
SPHysics –development of a free-surface fluid solver–Part1:Theory and formulations Computers & Geosciences 48(2012)289–299 equations 7&8 JSphCpu.cpp //.................................................................. // -Ace was previously initialised with value of gravity. //.................................................................. float acex=Ace[p].x-Gravity.x,acey=Ace[p].y-Gravity.y,acez=Ace[p].z-Gravity.z; float acex=Ace[p].x; float acey=Ace[p].y; float acez=Ace[p].z;
Comments
What you are seeing is not a bug so much as a design decision borne from the purposes DualSPHysics was originally designed for.
Basically, when you set gravity equal to {0,0,0} (or in fact anything other than {value,value,-value}) in the XML that you then feed into GenCase, it creates a beta constant that cannot be zero in the context of the SPH simulation portion (i.e. DualSPHysics). Unfortunately there is currently no way around this quirk, though it may be addressed in a future release (this is not my area).
If you are happy with modifying code then you can quite easily set gravity equal to zero yourself in the source and compile your own version. Other than that I suggest picking a very small value for gravity such that its effects are minimal in your simulation, i.e. {0,0,-1e-6}.
Hope that's of some use and apologies to the developers if there is some misinformation in there!
There could be a number of reasons your particles are escaping. Typically this is due to your time-step being too high or there being a slight geometrical inconsistency in the "forcefield" generated by the boundary particles because of bad placement of a particle, or it could be something less obvious such as the smoothing length or perhaps you have simply managed to define a case the boundary condition can't handle!
So first thing to do is load the output created by GenCase into your visualization tool of choice andcheck things look sensible at the boundaries.
The next thing to do is try to decrease the time-step that your simulation is taking. You say you are altering the time-step, how are you doing this? The actual time-step used is dynamically calculated based on a number of stability conditions. These are controlled by various global properties of the simulation (such as current maximum accelerations) but can be affected by changing the speed of sound coefficient so that the value for "Cs0" is raised (you can check the value calculated in the output of DualSPHysics when you first run it) or by altering the CFL value. Higher values for Cs0 will decrease the time-step (and of course increase computational time) whilst lower values of the CFL value will do the same. These properties do more than just alter the time-step of course, but at a very basic level this is what they do.
Getting a stable simulation is a tuning process I'm afraid, much like any CFD problem.
Can I suggest (if you haven't already) that you have a good read through the documentation provided with DualSPHysics, both the DualSPHysics guide and the GenCase guide as both give good information regarding the meaning of all the different parameters.
By taking gravity zero, the "B" becomes very small in Tait equation. Thus the fluid becomes too compressible and particles can squeeze and escape from boundaries. I think you need to find some way around this. increasing speed of sound is an option but having it too high could also lead to some other unphysical behavior between particles.
Cheers,
Jalal.
One potential solution for this is to do as you have been, allow GenCase to produce your input XML file, run the simulation once and make a note of the value for "Cs0" (speed of sound) that your parameters has produced, then correct the value of "B" in the XML file that GenCase produced.
You will find it towards the bottom of the file inside the tag. You can use the following to calculate a new value of B: (Cs0*Cs0*Rhop0)/Gamma. The problem with this is that using very low gravity, chances are you will also have a very low value for the speed of sound (likely the specific issue causing the particles to exit through the boundaries). So you may have to tweak the value of coefsound to a very high number in order to force things.
The problem here of course is that all of these values are in some way linked, with GenCase being designed to handle standard gravity scenarios only, so all of this amounts to hacking things.
Another solution is to take the source code and create your own copy of DualSPHysics in which you can define the value of Cs0 (and all associated variables such as
Hopefully in the future this is something that GenCase will handle correctly.
Please do let us know how you get on.
I figure there are two ways of doing this. One being manipulating the variables of DualSPHysics to force the program to work for my case, as you stated above. The other, which i've been trying to work on for the past few days, would be to make g=0 with respect to the boundaries. I've set up a simple 2-D case of a fluid circle dropping in a fully closed off box. I've been trying to add motion to the box so that it drops with the same acceleration as gravity using ''. The problem I've been running into is DualSPHysics saying the boundary has gone outside of the working domain. To try to fix this I've increased the pointmin and pointmax numbers to allow room for the domain to "fall" but this seems to have no effect. I will pursue your suggestions but was wondering if you had any ideas as to what might be the cause of this problem.
Thanks again
When you set a value for pointmin and pointmax in your XML that you feed in to GenCase, this is taken to be a suggestion for GenCase to use. Therefore GenCase then cuts your workspace down to what is actually needed.
The reason for this is that particle methods like SPH need a way of determining forces of neighboring particles (i.e. those within the smoothing length), to do this quickly the space is partitioned sing a grid-like structure. If you work on the premise that the potential simulation space is infinite (within the confines of single precision floating point) then you need an infinite amount of memory to divide the area, clearly not practical!
To avoid this it is desirable to keep static boundaries static, or at least ensure they remain within a definable area (i.e. a rotor spinning around an axis for example), therefore ensuring that the fluid particles also remain within this area.
Hopefully you can see why what you are trying to do doesn't work with DualSPHysics (or in fact any well engineered SPH code).
Really the best solution for you would be to download the source code and in there over-ride the value for "cs0" (speed of sound) and "b" so that they work for the accelerations in your system. Alternatively you could wait for the next release of DualSPHysics which I suspect will incorporate a number of solutions to your problem.
I am trying to understand how to remove gravity as well in my test case. Did anyone manage to do that?
In the simulation I am running, the fluid forces should only be due to the pressure gradient and viscous term, no body forces. I have tried to use very small gravity values as well as correcting the value of B, but that did not work. Any other suggestion?
A solution that I found while working on a zero g case was to scale the whole simulation up so that my acceleration due to gravity was equivalent to 1*e-6 m/s^2. The issue that I found in using dualsphysics for this is the lack of surface tension and wetting effects.
Hope that helps
Best,
Taffo
I also suspect the dynamic boundary conditions (only ones currently implemented) are just not suitable for such cases, as the noise in the pressure field generated by the boundaries without gravity to hold it down would become quite unstable, and several parameters (like B, Cs0 and artificial viscosity) would have to be tweaked just to get no penetration and stable results.
I have MUCH higher hopes for the delta-SPH formulation which should be introduced in version 3, to which you would still have to include at the very least surface tension to get realistic micro gravity flows.
the gravitational acceleration.
SPHysics –development of a free-surface fluid solver–Part1:Theory
and formulations
Computers & Geosciences 48(2012)289–299 equations 7&8
JSphCpu.cpp
//..................................................................
// -Ace was previously initialised with value of gravity.
//..................................................................
float acex=Ace[p].x-Gravity.x,acey=Ace[p].y-Gravity.y,acez=Ace[p].z-Gravity.z;
float acex=Ace[p].x;
float acey=Ace[p].y;
float acez=Ace[p].z;