← Back to team overview

yade-users team mailing list archive

Re: all yade users, please introduce yourself!


I didn't run that with InsertionSortCollider (it didn't exist back
then), but as seen from http://yade.wikia.com/wiki/Colliders_performace,
the collider should be about 2x faster. But it scales the same, so you
will get 80% of time in collider once you use 100k spheres again.
(BTW is it OK if I use InsertionSortCollider in TriaxialTest by default,
even without "fast"?)

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.

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.

(taucs has been last released in 2003, does that give you great deal of
confidence in its future?). How often are you going to solve the sparse
system? If at every step, most time will be spent there probably (unless
you have 100k+ particles).
Anyway, the size of the fluid problem scales with the number of partices. It won't be solve at each time step. Only the right-hand side of the problem will vary at each iteration (M.X=b with b varying all the time but M varying each N iterations, like above)

 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?

Let me ask this again before I start working on this :

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?

Anton: "Good to have YADE deb-package in repositories.". The
infrastructure is there, https://launchpad.net/~yade-users/+archive/ppa
has (one) package, but given the speed how yade evolves and until
recently, you couldn't practically use it without writing c++ code, it
didn't make much sense to distribute binaries.
You can still run triaxial tests with various number of grains, friction, granulometry, compacity, etc. Not a negligeable thing as the triaxial test is the first simulation for more than 50% of the dem users I think.

Hm, good point. I would like to release yade at  some near future point,
just for such purposes. Please add bugs and attach them to the 0.20-0
milestone so that we can track what rests to be done. It looks more or
less stabilized now.


Mailing list: https://launchpad.net/~yade-users
Post to     : yade-users@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-users
More help   : https://help.launchpad.net/ListHelp


Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43

Follow ups