I was working on some script and got strange issue with Dyverso's getNeighbors(Vector, float) function.
I created a sheet of particles (22x22 particles, resolution of Domain is 10). No external forces. Width of the sheet is 1m x 1m. So, the distance between particles is around 0.045. Emitter is not emitting.
Here is part of the code that I made for a test:
for particle in pList:
pPos = particle.getPosition()
pId = particle.getId()
#scene.message(str(pPos))
nList = dom.getNeighbors(pPos, 0.755) #searching distance 0.755
scene.message(str(len(nList)) + " neighbors of the particle " + str(particle.getId()))
if (nList > 0 ):
for nparticle in nList:
npPos = nparticle.getPosition()
dist = (npPos-pPos)
#scene.message("distance from particle " + str(nparticle.getId()) + " to the particle " + str(pId) + ": " + str(dist.module()))
So, the problem is that if I use searching distance that is 0.05 or so, the result is zero neighbors. I had to increase the radius dramatically. Even though, the result more then just strange. Most particles have zero neighbors, but some have 20-30 and more neighbors. I checked distance between a particle and it's neighbors. The distance is much much smaller then searching radius which is not surprising for me. I also tried very extreme radius value, 1.5, which is more then the width of the sheet of particles I've created. So, it should show me that each particle has 483 (22*22(particles in the domain) - 1(for this particle we are searching neighbors) = 483). The result is different. some particles have NO neighbors.
Pretty much the same code works well with Standard particles. With distance 0.05 it shows me 3-5 neighbors for each particle.
One more thing Voxelization() have no effect on simulation at all. Maybe I'm doing something wrong. Unfortunately, there is almost no information about Voxelization() function in Help. Maybe someone knows where it should be placed in a code?
Any ideas how to solve the problem or, at least, why it happens?
Thanks guys,
Andrey
Dyverso's getNeighbors()
-
- Posts: 178
- Joined: Tue Aug 29, 2017 12:35 pm
Re: Dyverso's getNeighbors()
Hi Andrey,
I'll take a look at this issue and let you know what I've found out.
I'll take a look at this issue and let you know what I've found out.
That's true, because you don't need it here. I know that the help says that it speeds up the search for neighbour particles, but in this case this is related to RF's internal process of finding neighbours, not the one you can access via scripting. A typical field of application for voxelization is when you insert particles in sheeter/hole filling scripts.One more thing Voxelization() have no effect on simulation at all.
Re: Dyverso's getNeighbors()
Oh, thanks for the informationThomas Schlick wrote: ↑Tue Jan 23, 2018 8:14 amThat's true, because you don't need it here. I know that the help says that it speeds up the search for neighbour particles, but in this case this is related to RF's internal process of finding neighbours, not the one you can access via scripting. A typical field of application for voxelization is when you insert particles in sheeter/hole filling scripts.One more thing Voxelization() have no effect on simulation at all.
Re: Dyverso's getNeighbors()
One more thing I forgot to mention.
Pretty often a list of neighboring particles contains the particle we are looking neighbors for. Here is the text form the Message box:
>[24/January/2018 12:07:56] - 0 neighbors of the particle 396
>[24/January/2018 12:07:56] - 0 neighbors of the particle 440
>[24/January/2018 12:07:56] - 2 neighbors of the particle 462
>[24/January/2018 12:07:56] - distance from particle 462 to the particle 462: 0.0
>[24/January/2018 12:07:56] - distance from particle 484 to the particle 462: 0.0270042922348
>[24/January/2018 12:07:56] - 1 neighbors of the particle 484
>[24/January/2018 12:07:56] - distance from particle 462 to the particle 484: 0.0270042922348
>[24/January/2018 12:07:56] - end of of step
Pretty often a list of neighboring particles contains the particle we are looking neighbors for. Here is the text form the Message box:
>[24/January/2018 12:07:56] - 0 neighbors of the particle 396
>[24/January/2018 12:07:56] - 0 neighbors of the particle 440
>[24/January/2018 12:07:56] - 2 neighbors of the particle 462
>[24/January/2018 12:07:56] - distance from particle 462 to the particle 462: 0.0
>[24/January/2018 12:07:56] - distance from particle 484 to the particle 462: 0.0270042922348
>[24/January/2018 12:07:56] - 1 neighbors of the particle 484
>[24/January/2018 12:07:56] - distance from particle 462 to the particle 484: 0.0270042922348
>[24/January/2018 12:07:56] - end of of step
-
- Posts: 178
- Joined: Tue Aug 29, 2017 12:35 pm
Re: Dyverso's getNeighbors()
Hi again,
I've recreated your scene with a 22 x 22 particle matrix of 1m x 1m, and let your script run over the particles. Two things:
1. In my scene, the script gives correct results and I have between 3 and 5 neighbours per particle. The radius is 0.05.
2. I've made a mistake regarding the createVoxelization() function and simply forgot that it has a relevance in conjunction with Dyverso. But here you really won't see any performance boost, since a) the number of particles is simply not high enough, and b) the scene.message() output is what really slows down everything. These text outputs are everything but cheap, but of course they're necessary for debugging.
Here's a screenhot from my tests: https://picload.org/view/ddiprdai/dyver ... s.png.html
So, my questions is: which RF version are you currently running? The latest available version 10.1.2.0162 and - if I recall correctly - contains some improvements on this particular Python function.
I've recreated your scene with a 22 x 22 particle matrix of 1m x 1m, and let your script run over the particles. Two things:
1. In my scene, the script gives correct results and I have between 3 and 5 neighbours per particle. The radius is 0.05.
2. I've made a mistake regarding the createVoxelization() function and simply forgot that it has a relevance in conjunction with Dyverso. But here you really won't see any performance boost, since a) the number of particles is simply not high enough, and b) the scene.message() output is what really slows down everything. These text outputs are everything but cheap, but of course they're necessary for debugging.
Here's a screenhot from my tests: https://picload.org/view/ddiprdai/dyver ... s.png.html
So, my questions is: which RF version are you currently running? The latest available version 10.1.2.0162 and - if I recall correctly - contains some improvements on this particular Python function.
Re: Dyverso's getNeighbors()
Thanks for helping Thomas
Yeah, I know that displaying text takes much time
Ok I found the problem.
I tried the script in batch mode as you did it, and I got the same problem I had before. Then I installed a demo version of Realflow on my laptop and created the same project. Everything worked without any problem. So I start thinking what's the difference between newly installed program and the one I have on my workstation. Luckily I made just few changes in settings only. At first I thought I thought that it's because of the font I used. Well, I was wrong. The last thing that was different on my workstation's Realflow is Axis setup. It was set to 3D MAX, May. As soon as I changed it back to Lightwave, the script worked without any problem. Actually, yesterday I've started suspecting that something is wrong with presentation the location coordinates of the particles in space or something like that. So there is some kind of bug with coordinates transformation from one space to another.
So, I can use createVoxelization() to improve searching speed when I have many particles, am I right? If so, how I should use this function? Where should I initialize it in a script?
Thank you one more time
My respect ,
Andrey
Yeah, I know that displaying text takes much time
Ok I found the problem.
I tried the script in batch mode as you did it, and I got the same problem I had before. Then I installed a demo version of Realflow on my laptop and created the same project. Everything worked without any problem. So I start thinking what's the difference between newly installed program and the one I have on my workstation. Luckily I made just few changes in settings only. At first I thought I thought that it's because of the font I used. Well, I was wrong. The last thing that was different on my workstation's Realflow is Axis setup. It was set to 3D MAX, May. As soon as I changed it back to Lightwave, the script worked without any problem. Actually, yesterday I've started suspecting that something is wrong with presentation the location coordinates of the particles in space or something like that. So there is some kind of bug with coordinates transformation from one space to another.
So, I can use createVoxelization() to improve searching speed when I have many particles, am I right? If so, how I should use this function? Where should I initialize it in a script?
Thank you one more time
My respect ,
Andrey
-
- Posts: 178
- Joined: Tue Aug 29, 2017 12:35 pm
Re: Dyverso's getNeighbors()
I'm glad to hear that your script is working now. Thanks for letting me know.
The voxelization should be done before the neighbour search to establish the data structure:
To be on the safe side I was also browsing our bug list and there's a certain syntax with createVoxelization() that crashes RF, but with the code above everything works fine. Anyway, please be careful and if you experience crashes or other problems, e.g. high RAM usage, I recommend not using this function.
And finally for the transformation of coordinates: may I ask you to contact our helpdesk via the customer portal? There's not very much I can do here. Thank you!
The voxelization should be done before the neighbour search to establish the data structure:
Code: Select all
DY_Domain01.createVoxelization()
for particle in DY_Domain01.getParticles():
n = DY_Domain01.getNeighbors(p.getPosition(), 0.05)
And finally for the transformation of coordinates: may I ask you to contact our helpdesk via the customer portal? There's not very much I can do here. Thank you!