yade-users team mailing list archive

[Václav Šmilauer <eudoxos@xxxxxxxx>]

> Ok, I'm discovering this new collider now. 2x faster? That is good.
> But I don't understand why a collider scaling with Nparticles is so bad, 
> other engines scale the same way don't they?
> Did you implement the x/y/z threads trick for parallel collider?
> Ok for using it in triaxial test.

It scales N*log(N) (theoretically), and that is bad enough (black and
red curves at http://yade.wikia.com/wiki/Colliders_performace ).  

It is bad because efficiency of parallelization (of the interaction
loop) grows with number of particles - as one step takes longer time,
the constant overhead of parallelization scheduling (etc) gets
proportionally smaller. And this nice effect is pretty much killed by
the collider.

> Another option, for quasistatic simulations, is to use triangulation or 
> one of the old collider with radiusFactor = 1.2, and update the contact 
> list only once per N iterations. Depending on max velocity in the model, 
> N can be set to at least 10. You can adjust N during runtime 
> automatically if maxVel increases somewhere. In some very slow 
> compression tests, N could really be 50 or so.
Agreed. But is there such collider written? (I know there are papers
about that.) What is the computation complexity of triangulation
collider? I know that the grid-based ones achieve O(N), but we don't
have that implemented either.

> >  If taucs runs multi-threaded (it seems it
> > does), it may interact badly with openMP threads which will be allocated
> > independently. You will see.
> >   
> Mmmmh... Interesting, but not a very good news. Taucs works impressively 
> well in single thread. Do you know anything equivalent designed for openMP?
Maybe 
http://software.intel.com/en-us/intel-mkl/, but there must be more, I am
quite sure. But you can easily limit current number of threads for
openMP and allocate those to taucs, or just let the OS do the
thread-battle by itself. 

> I confirm that the current behaviour of ElasticContactLaw (requesting 
> deletion of interactions as soon as contact is lost), disable capillary 
> forces between distant grains.
> I'm about to implement a "interactionDetectionFactor" in ElasticLaw the 
> same way as in 
> InteractingSphere2InteractingSphere4SpheresContactGeometry, and delete 
> interactions only if distance is larger than (r1+r2)*factor.
> 
> Anybody has a better idea?

Before, it was the geometry functor deciding on which interaction to
delete (and there had to be IS2IS4SCGWater), now this responsibility
shifted to the constitutive law; so it is logical.

Wouldn't it be better, however, to create a separate constitutive law? I
fear a little that at some point everybody will ad his/her own
parameters into ElasticContactLaw. Maybe not grounded, though; this one
distanceFactor seems OK to me.

Don't add it to ElasticContactLaw, however, but to
ef2_Spheres_Elastic_ElasticLaw (shouldn't it be renamed to
Law2_Spheres[ContactGeometry]_Elastic[ContactInteraction]_Elastic for
clarity) and use ConstitutiveLawDispatcher/InteractionDispatchers.
ElasticContactLaw is nothing but loop around calls to
ef2_Spheres_Elastic_ElasticLaw with typecheck. Slower and
non-parallelizable.

Oh, BTW, is there agreement on having useShear by default and
progressively remove prevNormal from various InteractionPhysics classes?

Vaclav