search

VasiliBaranov / packing-generation

Hard-sphere packing generation in C++ with the Lubachevsky–Stillinger, Jodrey–Tory, and force-biased algorithms and packing post-processing.
MIT License
106 stars 43 forks source link

Force-biased algorithm problem #3

Open sbls456 opened 7 years ago

sbls456 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 16 35

Best regards Tommy Su

VasiliBaranov commented 7 years ago

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 commented 7 years ago

Dear Vasili,

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

Best Regards, Tommy Su