yade-users team mailing list archive
-
yade-users team
-
Mailing list archive
-
Message #00267
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?
Bruno
--
_______________
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 : 04.56.52.86.21
________________
_______________________________________________
Yade-users mailing list
Yade-users@xxxxxxxxxxxxxxxx
http://lists.berlios.de/mailman/listinfo/yade-users
Follow ups
References
