Hi all,
In order to simulate a gaussian radius distribution for particles I used different fix particletemplate/sphere, each with a different constant radius.
Then I simulate the distribution via a fix particledistribution/discrete/numberbased command. Currently I use 11 different fix particletemplate/sphere commands.
If I use a fix insert/rate/region command to create the particles everything works fine.
If I use a fix/insert/pack command instead, wrong particlesizes in completely wrong numbers are created. In general, the created radi are way too big on average.
If I use the old (and recently removed) fix particletemplate/sphere with gaussian radius, everything works fine (correct particle sizes are created in gaussian distribution).
The small liggghts script in the attachments can reproduce the bug. Only 6 out of the 11 fix particletemplate/sphere are used by the insert command.
Best regards
Bernhard
| Attachment | Size |
|---|---|
 test.txt | 3.28 KB |
Daniel Queteschiner | Thu, 12/07/2017 - 10:22
Any warnigns?
Do you by any chance get the warning:
"Particle insertion: Less insertions than requested"?Bernhard | Thu, 12/07/2017 - 11:22
Yes, this warning exists and
Yes, this warning exists and I seem to have overlooked it.
I've made a couple more tests and it seems that whenever you use a higher volumefraction than 0.2 (which is in my opinion a very low packing value) the script already has problems inserting the number of requested particles and bugs out. As the script wants to achieve a "higher" volumefraction, it inserts the bigger particles first and thus the distribution is not correct anymore (unless you use the removed gaussian distribution).
Another thing is the maxattempt command (its default value is 50). If you set this value to 10000 (or even higher) then insert/pack command gets significantly better. With 10000+ maxattempts you can get a volumefraction of 0.3 (personally I would still like a higher one).
One could always turn overlapcheck off, but then (because of the overlap of the particles) the simulation gets unrealistic. Also, even if the script says that it has inserted enough particles on the first try, it keeps inserting more particles (if you change insert_every once to some other timestep) if overlapcheck is turned off.
Daniel Queteschiner | Thu, 12/07/2017 - 12:52
Packing
You will not get a higher packing density with the implemented insertion algorithm. It's a simple sequential inhibition method, which - as you have observed correctly - inserts particles randomly from largest to smallest. If during such an insertion step no empty space is found for a particle, the insertion is simply aborted (even if there would be enough space for a smaller particle still waiting to be inserted). Thus you typically get a different size distribution preferring larger particles.
To create a denser packing you either have to use a larger insertion region and compress the particles (or just let them settle) or you have to implement a different insertion algorithm, e.g. (as we have done in our version of LIGGGHTS) following the paper by Lozano et al. "An efficient algorithm to generate random sphere packs in arbitrary domains", Computers & Mathematics with Applications, 71, 8, 2016, p. 1586-1601
@DCS developers: Could this issue be clearly mentioned (as a note box or something similar) in the manual? I've stopped counting how many times I have come across this question in the last couple of years ...
arnom | Mon, 12/11/2017 - 11:32
Hi Daniel,
Hi Daniel,
thanks for your recommendation. We are currently thinking of overhauling the warning system as things like these often get overlooked. We were thinking of generating an extra log file that contains only warnings. In this way, the user would have immediate access to all produced warnings. Do you think this would solve the issue?
Best,
Arno
arnom | Mon, 12/11/2017 - 11:39
Also there will be a warning
Also there will be a warning in the documentation that references this printed warning explicitly.