runSort(), sortPostPass(), index()

[mlolson]

@tarelli @gidili @a-palyanov Couple questions: Whats the reason for sorting the particles at each step? Also what are sortPostPass and index doing? I'm trying to understand the algorithm that is being performed at each step. thanks!

[a-palyanov]

Particles are located within a 3D grid with total number of cells = nx_ny_nz. Every grid cell, depending on its coordinates, has its unique value of hash function (spatial index). Each particle has the same value as its current grid cell. We need to sort the array containing particles' hashes because only in this case we can access each particle's neighbours (only those particles, which are located in the same and adjacent grid cells) addressing them in the array just by knowing their coordinates. If this array in unsorted, then we'll need to compare distance between i and its potenital neigobour particle j for all values of j, instead of a small number of particles inside cells adjacent to i-th particle cell. There is some more information about this here: http://developer.amd.com/wordpress/media/2012/10/SmoothedParticleHydrodynamics.pdf

[mlolson]

@a-palyanov I see, that makes sense. Thanks for the info. It looks like here values are pulled out of the buffer, sorted on the cpu, then put back. Is there a reason for that? Sorry, my understanding of OpenCL is pretty limited.

[a-palyanov]

@mlolson The reason for this was the simplicity of this way. We needed to see how it works - for the first time, to debug and tune SPH simulator - it was a hard problem. Additionally, when we computed and compared time comsuption of each function working in the code, we found that even such 'non-optimal' sorting is far from being top time-consumptive stuff, so we kept it as is until current time. Of course it would be nice to replace it with OpenCL version of sorting working on GPU, but there are always more actual tasks.

[mlolson]

@a-palyanov I see. One more question: I have Sibernetic running in my local machine using the default example particle set. Suppose I wanted to test it with a larger number of particles. Is there an easy way of setting up such a simulation?

[a-palyanov]

@mlolson What is the scene ("default example") which you want to modify? It contains only some volume of liquid or something more?

[gidili]

@mlolson use to be that you can load a scene from a file. @skhayrulin did a lot of work around that and created a generator of configurations for Sibernetic [https://github.com/openworm/ConfigurationGenerator]. Not sure if the loading still works in the latest version, I sure hope so!

[tarelli]

@mlolson if it's about "understanding the algorithm" and you want to try different simulations the easiest thing for you could be to load different simulation files in geppetto, in the drop down menu there are two as you know but you can create as many as you want (the simulation in Geppetto are defined in an XML file, decoupled from the code, e.g. https://raw.githubusercontent.com/openworm/org.geppetto.samples/master/SPH/ElasticSmall/sphModel_elastic_1575.xml).

[mlolson]

@a-palyanov I mean the scene that is loaded when I run the command "./build/Smoothed-Particle-Hydrodynamics". I'm assuming it's the scene that is specified in the txt files under /configuration?

@gidili Thanks I'll check it out

@tarelli Ah yes, that might be easier. Is there a script for creating these scenes? I want to test with a lot of particles, like ~10^6. Maybe "big liquid elastic" will work for me.

[gidili]

@mlolson the configuration generator I linked generates both Sibernetic and Geppetto scenes btw!

[mlolson]

Alright, I'll try it out thanks!

[tarelli]

@mlolson https://github.com/openworm/org.geppetto.samples/tree/master/SPH/LiquidElasticBig this is a big scene with both elastic/liquid matter, you might want to start from that!

[mlolson]

@a-palyanov @gidili What is the reason for running four pcisph kernels 3 times at each step?

https://github.com/openworm/org.geppetto.solver.sph/blob/master/src/main/java/org/geppetto/solver/sph/SPHSolverService.java#L923

[gidili]

@mlolson basic idea is that every time you run those predict/correct Kernels it will get closer and closer to an acceptable approximation of the pressure force based on predicted position and density. All this magic happens in the kernels so it's hidden from the Java host code. As per comment: // LOOP: 3 times or until "error" becomes less than 2% I am guessing Andrey empirically tested that doing it 3 times is pretty much equivalent to measuring the error and then stopping when it's < 2%.

@a-palyanov should be able to explain in more detail as he designed the algorithm, I merely helped port it to Geppetto.

[a-palyanov]

In the Predictive-Corrective Incompressible SPH paper (Solenthaler et. al., 2009) we can find the following text about this: "To limit temporal fluctuations in the resulting pressure field we found it advantageous to employ a minimum number of iterations in the pressure update loop. This gives the particles enough time to propagate information about predicted particle locations. We found a minimum of 3 iterations generally sufficient to achieve a low level of pressure fluctuations."

[tarelli]

Guess this was answered from Andrey.