> 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.
>
> 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
>
>
>   


-- 
 
_______________
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
________________


_______________________________________________
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

Reply via email to