Yade

compressed packing of a small number of aggregates

Asked by rhaven

Hi There,
I am working on generating a compressed packing of aggregates. I am currently using /examples/agglomerate as a basis.
I am using makeClumpCloud to fill a cuboid with clumps which I generated. Then I would like to run them through /examples/agglomerate/compress.py and generate a dense packing of these aggregates.

I would like the method to work for just a few aggregates as well as for a larger number.
The result using just a few looks like http://pasteall.org/pic/index.php?id=116817
(When I generate a larger number of particles things look better http://pasteall.org/pic/index.php?id=116816)

As you see from the first image, there are fewer particles left after the compression. Why is this the case?

Does this have something to do with periodicity? Am I only seeing some of the particles? If so, how do I export all particles within my volume.
In case I am going about this wrong, how should I generate the packing of aggregates and then compress them such that I end up with a cuboid of packed aggregates (when the total number of particles is ~200)

many thanks in advance!
Jesse

the compress code is shown below.

from yade import export,ymport
 import random
 random.seed(1)

 # add walls first
 #dim = (15,15,15)
 dim = (1e-6,1e-6,1e-6)
 walls = aabbWalls(((0,0,0),(dim)))
 wallIds = O.bodies.append(walls)

 # load spheres from file, including information of their agglomerates ids
 attrs = []
 sp = ymport.textExt('/tmp/divided.txt',format='x_y_z_r_attrs',attrs=attrs)
 n = max(int(a[0]) for a in attrs)+1
 colors = [randomColor() for _ in xrange(n)]
 agglomerates = [[] for _ in xrange(n)]
 for s,a in zip(sp,attrs):
  aa = int(a[0])
  s.agglomerate = aa
  s.shape.color = colors[aa]
  agglomerates[aa].append(s)
 for a in agglomerates:
  O.bodies.appendClumped(a)

 #getClumpInfo()

 O.engines = [
  ForceResetter(),
  InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()]),
  InteractionLoop(
   [Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()],
   [Ip2_FrictMat_FrictMat_FrictPhys()],
   [Law2_ScGeom_FrictPhys_CundallStrack()]
  ),
  TriaxialStressController(
   thickness = 0,
   stressMask = 7,
   internalCompaction = False,
   label = 'compressor',
  ),
  NewtonIntegrator(damping=.6),
 ]
 O.dt = PWaveTimeStep()

 # compress the sample
 compressor.goal1 = compressor.goal2 = compressor.goal3 = -1e-7
 #compressor.goal1 = compressor.goal2 = compressor.goal3 = 1e-10
 O.run(50000,True)
 #compressor.goal1 = compressor.goal2 = compressor.goal3 = -1e-5
 #O.run(30000,True)

 # save the result, including information of agglomerates which the particle belongs to
 export.textExt('/tmp/compressed.txt','x_y_z_r_attrs',attrs=['b.agglomerate'])

Question information

Language:
English Edit question
Status:
Solved
For:
Yade Edit question
Assignee:
No assignee Edit question
Solved by:
Jan Stránský
Solved:
Last query:
Last reply:
Revision history for this message
Jan Stránský (honzik) said : 		#1

Hello,
do you have any evidence (other than visual) that there are fewer particles?
Could you try to to print pos, ori, mass and inertia of each sphere and agglomerates? If some of them is NaN, it could be the problem
For further testing, please privde also divided.txt file
cheers
Jan

Revision history for this message
rhaven (rhavenj) said : 		#2

Hi Jan,
Thank you for your reply
Here is divided.txt http://pasteall.org/454267/text
You are right about the NaN there are a whole bunch of them
compressed.txt http://pasteall.org/454268/text

What does this mean?
Best
Jesse

Revision history for this message
Jan Stránský (honzik) said : 		#3

> You are right about the NaN there are a whole bunch of them .. What does this mean?

from my experience, most of the time this is because of too large time step. Try to use
factor = 0.1 # trial-and-error value
O.dt = factor * PWaveTimeStep()

let us know
Jan

Revision history for this message
rhaven (rhavenj) said : 		#4

Hi Jan,
I tried with factor = 0.1, factor = 0.01, 1e-8, 1e-10
but the result is still nan positions, (the simulation also doesnt take any noticable time longer.. is that normal?)
Is there another value i should try or another likely cause?
thank you
Jesse

Revision history for this message
Jan Stránský (honzik) said : 		#5

I have tried the simulation with divided.txt. After one step, one agglomerate disappears. Before the first step, it has two colors, which is suspicious. Could you try, if after makeCloud stage there is not the situation that same spheres are overlapping?
Jan

Revision history for this message
rhaven (rhavenj) said : 		#6

Hi Jan,
Some of the spheres in the clumps are overlapping, this is from when I first generate the clumps/aggregates with makeCloud. Then these clumps go into makeClumpCloud, here i am not sure if the clumps overlap with other clumps.
Best,
Jesse

Revision history for this message
Best Jan Stránský (honzik) said : 		#7

I am not falmiliar with makeClumpCloud at all.. but the first problem is that clump disappearing and the only suspicious circumstance is that it contains particles of two colors (unlike all other clumps). All othe values (pos, vel, ori, mass, inertia ...) also seems ok.

I have tried to find particles with identical positions, there are a lot of them, which also might be a problem:
####### at the end of the code, without any run
ids = set(b.id for b in O.bodies)
sames = []
while ids:
   i = ids.pop()
   b = O.bodies[i]
   p = b.state.pos
   same = [i]
   iis = set(ids)
   for ii in iis:
      bb = O.bodies[ii]
      if bb.state.pos == p:
         same.append(ii)
         ids.discard(ii)
   if len(same)>1:
      print "bodies {} has identical pos".format(same)
      sames.append(same)
for i in sames[-1]:
   print O.bodies[i].state.pos
#######

good luck in debugging :-)
Jan

Revision history for this message
rhaven (rhavenj) said : 		#8

Hi Jan,
I've removed the clump which has multiple colors, using O.switchScene(); O.resetThisScene() to make sure that everything was clean before I used makeClumpCloud.

Now back in compress.py I added your code to search for bodies with the same position, and the only result is always the last body in O.bodies, (which probably has to do with poping the list)
bodies [575, 575] has identical pos
Vector3(4.3431775000000003e-7,1.2615049999999998e-6,6.8119425e-7)
Vector3(4.3431775000000003e-7,1.2615049999999998e-6,6.8119425e-7)

as well the NaN particles have also disappeared from compressed.txt. which is great. Furthermore, there dont seem to be any more particles which are disappearing. I guess this was all due to that one multicolored clump?...

However, the issue is that I still dont end up with a cuboid of particles. The compression step doesnt seem to be doing anything. The volume looks half empty..

Is it possible to force more and more clumps to be added until some condition is reached? Similar perhaps to the periodic-grow example? I will start a new question though.

thanks again
Jesse

Revision history for this message
rhaven (rhavenj) said : 		#9

Thanks Jan Stránský, that solved my question.