Force-biased algorithm problem

[sbls456]

Dear:

I used the "PackingGeneration.exe -fba" to run the code.
When i set that the particles count were 309 and the dimensions were 20 20 16, the inner diameters ratio would be very small and failed.
When i used the dimensions are 35 35 28.9, the result was fine.
Does the code have a limit of the dimensions or other issues needed to be noticed?
Thanks for help!

Tommy

[VasiliBaranov]

Hi Tommy,

sorry for a late reply. May be it can still be relevant to you. Or may be it will be relevant to someone else. One possible reason for the problem can be the following. The results of the FB algorithm depend on the contraction rate that you specify in the generation.conf and also on the expected volume fraction (packing density) of particles in the box (as if they have no intersections). If you use the box [20 20 16] and the same number of particles, the expected density will of course be higher than in the case [35 35 28.9]. You may try to decrease the original particle diameters proportionally to maintain the same expected density for the case [20 20 16]. Or you may try to scale the box sides proportionally, i.e. use [20 20 16] * (35 * 35 * 28.9)/(20 * 20 * 16)=[110.63 110.63 88.5]. I've added a corresponding section to the Readme and also one more related section. If this does not help, please contact me (i'm monitoring the issues closer now :-) ).

Hope this helps,
Vasili

[sbls456]

Dear Vasili,

Thanks for the reply!!!
But I lost some information on top question....
I used the settings that the particles count were 309 and the dimensions were 20 20 16.
And another one is "the particles count were 1657" and the dimensions were 35 35 28.9.
Both packing density (volume fraction) of them were about 0.6.
The following link had two files ("diameters" "generation.conf ") i used.
https://drive.google.com/open?id=0B9Bx1gbMVek3dVRxdEhqeDVCTGc
Otherwises, The Screen grab of the results were

Best regards
Tommy Su

[VasiliBaranov]

Hi Tommy,

thanks for your screenshots and configs. I was indeed able to reproduce this bug. I uploaded the fixes and created a new release where the bug seems to be fixed. I was mostly developing the program on the svn server in our research lab and it seems that i have already fixed this bug some time ago, so i just merged the updates from the svn server to this github repository. The new code produces exactly the same packing for 35 35 28.9, but also produces a valid packing for 20 20 16. If you have any other questions or problems, please contact me/submit an issue/comment on this issue.

Best Regards,
Vasili

[sbls456]

Dear Vasili,

It works pretty well. Thanks for the help!!!

Best Regards,
Tommy Su