> 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 _______________________________________________ Mailing list: https://launchpad.net/~yade-users Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp _______________________________________________ yade-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/yade-users
