Jump to content

  • Log In with Google      Sign In   
  • Create Account


Wrong result for ported SPH Simulation


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Finalspace   Members   -  Reputation: 239

Like
0Likes
Like

Posted 01 July 2013 - 11:51 PM

Hi there,

 

i am currently trying to port a working SPH - Smoothed Particle Hydrodynamics 2D implementation to Javascript with the simplest methods possible. Original code see here: http://www.opentk.com/node/377

 

After some days i got some results which moves particles but behaves really weird - Particles just pushes other particles away and does not behave correctly. The main problem is - SPH is based on heavy maths and i dont understand the details at all - Therefore fixing issues is really hard. Dont get me wrong, i have some experience with vector maths, collisions and response, see this demo: http://root.xenorate.com/final/physics/circles.html (Circle/Plane Collision with TOI handling and collision response)

Therefore i understand vector arithmetic a little, but SPH is just a little to hard to figure out myself. Also i made a fully working 3D Fluid Simulation in the past, but using PhysX as a Physics Engine: See this demo i made: http://www.youtube.com/watch?v=eUbwxTE38TY

Now i wanted to try to make this myself, without using a physics engine at all.

Please have a look at my javascript SPH port: http://jsfiddle.net/gRUKg/1/

 

Currently my implementation does not handle every aspect from the original source, i use a diffent spatial grid technique and the viscosity and adjust distance code is disabled (Not required to get this working)

 

It would be really great if you can help me to get this thing working. I really want to understand the details behind it, for tuning the properties and improve it. Of course i read several SPH papers, but i cannot understand this at all.

 

Thanks in regards,

Final


Edited by Finalspace, 02 July 2013 - 12:26 AM.


Sponsor:

#2 LorenzoGatti   Crossbones+   -  Reputation: 2662

Like
0Likes
Like

Posted 02 July 2013 - 02:10 AM


Currently my implementation does not handle every aspect from the original source, i use a diffent spatial grid technique and the viscosity and adjust distance code is disabled (Not required to get this working)

A pedantically faithful port would be easier to write. You admit being out of your depth with this project, so you should avoid imprudent attempts to be clever like messing with the basic grid structure or deciding that some parts of the algorithm aren't "required". I was going to suggest a careful review of your code and the original to find subtle differences in calculations, but deliberately doing something else in a different way makes this approach impossible.
Produci, consuma, crepa

#3 brucedjones   Members   -  Reputation: 441

Like
0Likes
Like

Posted 02 July 2013 - 07:09 AM

Can you show an animation from your current implementation?

 

I suspect you are getting this behavior because you have not included viscosity. The SPH algorithm has artificial viscosity terms for damping (dissipating energy), this is required even when modelling an inviscid fluid.

 

You may want to check your simulation parameters as well. Incorrect choice of time step or integration kernel range will lead to unstable solutions.



#4 Finalspace   Members   -  Reputation: 239

Like
0Likes
Like

Posted 02 July 2013 - 11:27 AM

Can you show an animation from your current implementation?

 

I suspect you are getting this behavior because you have not included viscosity. The SPH algorithm has artificial viscosity terms for damping (dissipating energy), this is required even when modelling an inviscid fluid.

 

You may want to check your simulation parameters as well. Incorrect choice of time step or integration kernel range will lead to unstable solutions.

 

You can see the animation if you click on the jsfiddle link in my post.

 

Also i modified the original source (c#) and disabled the viscosity and distance adjust part just to make sure, what the basics are.

And it works just fine without viscosity force, of course it is a lot more stable with viscosity. Thats for sure.

 

 

 

Currently my implementation does not handle every aspect from the original source, i use a diffent spatial grid technique and the viscosity and adjust distance code is disabled (Not required to get this working)

A pedantically faithful port would be easier to write. You admit being out of your depth with this project, so you should avoid imprudent attempts to be clever like messing with the basic grid structure or deciding that some parts of the algorithm aren't "required". I was going to suggest a careful review of your code and the original to find subtle differences in calculations, but deliberately doing something else in a different way makes this approach impossible.

 

 

Yeah i know, but i think i wont learn not much from that - normally i would break down an implementation to see what happens if i modifiy/disable several parts, like disabling the global force or viscosity force or distance adjust stuff. Thats my normal way of doing things, but i think porting it directly without changes at all is a better approach right now. I will post again if i finished the port.
 



#5 brucedjones   Members   -  Reputation: 441

Like
0Likes
Like

Posted 02 July 2013 - 08:37 PM

So I just had a look at your JSFiddle. I reduced the particle mass to 1, from that it appears that the motion of the particles is just to acheive an equilibrium configuration. This is more obvious when you add lots of particles, and turn off the boundaries, notice how the packing becomes very regular. This is normal behaviour as particles are not initialised in their equilibrium configuration.

 

With a reduced mass, the body force implementation appears to be working as well.

 

Your boundary collision however is not conserving momentum, and is causing a very unstable solution.



#6 Finalspace   Members   -  Reputation: 239

Like
0Likes
Like

Posted 04 July 2013 - 12:02 AM

Ok i ported it successfully and it works fine so far.

There was some things which had troubled me while porting and some things i learned:

 

- Javascript does weird things with arrays like this: var arr = [,];

- yield return idx; is a really shit shortage for a concatination of an interation in C# :(

- domain resolution should be left in a smaller range, otherwise it is too slow or somehow unstable.

 

Here is the result:

http://jsfiddle.net/Qy9SX/1/

 

Now the next step is to change the spatial grid technique to a dynamic one and implement basic collisions to simulate the boundary.

 

Thanks for your help so far.



#7 brucedjones   Members   -  Reputation: 441

Like
0Likes
Like

Posted 04 July 2013 - 12:42 AM

Looks good.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS