← Back to team overview

yade-users team mailing list archive

Re: call for code


PS: Bruno I have ran your triaxial test that you have send to Yuannian,
it seems to work good.

Well... not completely in fact. The eigen-period of grains is computed considering only translations, it appears that the most critical movement can be rotational (I remember one previous e-mail where you asked : "what about rotations?", you were right). This is currently partially balanced by coefficient of secutity applied on the computed time-step, but I would prefer computing a more precise time-step including rotational effects. It just requires including 3 more components to the "stiffness" parameter. Also : current TriaxialTest is not exactly a triaxial test, because stress is always isotropic. The conclusion is : those file will still change (I must also include few important comments e.g. to explain that using StiffnessMatrixTimeStepper requires that StiffnessMatrix is added to physical actions).
So perhaps it is not time to include all this in the release.

If you don't send me any updates I'll put this
version into the next release.

Please, could you give me a deadline for sending my files? It is better if I send you the most up-to-date files at the moment you will start working on Yade.

If you plan working on Yade soon, and if you don't mind, I would like to discuss one aspect related to computation times. Few months ago, I realised that cycling only one time through all interaction is more time-consumming than expected. I investigated a little bit and I now think it was due to shared_pointers that induce mutex lock/unlock each time they are manipulated. I planned to send you some Kcachegrind outputs to discuss this with you, but you had a PhD to do... I have only a very vague idea of what means locking/unlocking a mutex... I presume this is due to multi-threading, then I wonder if it possible to avoid this when not using the OpenGL display... or perhaps simply declaring appropriate _const_ shared_ptr (when possible) would reduce the cost of those manipulations... I don't know. The CPU time associated with StiffnessCounter could be divided by a factor of 3 (!), if the cost of iterrating over all interractions (I mean "++iterator" operations from begin() to end()) was negligible compared to the cost of the mathematical operations done in this engine! I have many ideas in mind to improve Yade speed (my ideas are in term of DEM algorithms, not implementation of them). The problem is, currently all my ideas would have a small effect because they are related to some parts of Yade that represent only ~30% of the total CPU time. If the cost of operations like (iterator<shared_ptr<interaction>>)++ or (iterator<shared_ptr<body>>)++ was reduced to a cost more comparable to the one of a classical (iterator<interaction*>)++, those 30% could become 60%, or even more. Then the ideas I have in mind would become more profitable. I think the overall effect could be significant in the case of a triaxial test.

What is your opinion on all this?


Chareyre Bruno
Maître de conférence

Institut National Polytechnique de Grenoble
Laboratoire 3S (Soils Solids Structures) - bureau I08
BP 53 - 38041, Grenoble cedex 9 - France Tél :

Yade-users mailing list

Follow ups