This is very interesting, thank you.
Do you have ideas on what should be done in Yade to improve parallel
performance (or, say, what is currently limiting the number of
processors)? In my last benchmarks, I had almost 70% time on
interactions, and I'm still curious to know why this cannot be improved,
as it sounds a easy-parallelizable thing.
Bruno
Václav Šmilauer a écrit :
Hi everybody,
me and Anton have both attended course on DEM software ESyS-Particle
https://launchpad.net/esys-particle/ in Aachen last week, which was a
very nice event with lots of informations. I would like to share that
with you, as it might be relevant to your research / work on yade.
Their software is very good, to start with, has 10+ years of development
behind it, with a few people working on it full-time; IIRC the
development mainly goes on in Australia (Queensland, Brisbane?), and one
of the leaders, Steffen Abe, is now in Aachen.
1. ESyS is _really_ high-performance (routinely 1e7 particles), able to
scale to hundreds of CPU cores and to be fast. The package is build from
ground-up to run in parallel and does it well: e.g. they use the grid
collider (a variation of the Munjiza's BoBinarySearch algorithm, which
scales linearly), there is no runtime-dispatching to avoid wasting time
etc.
2. ESyS has quite good documentation (see their website), including
tutorials, (quite stable) API documentation and so on.
3. ESyS was written to do one thing and to do it well -- DEM (spheres +
triangulated meshes, infinite walls) with only a few interaction models;
if you want to add your own constitutive law (there is a tutorial on
that), you have to touch code at many different places (less convenient
than our plugin way).
4. ESyS doesn't support saving simulations at arbitrary point and
restarting later (as far as I understood). Along with the absence of
dispatching logic, this allows to not have extended RTTI as yade classes
have to have (REGISTER_CLASS and so on).
5. There is no ui, simulations are constructed in python, postprocessing
done using various converters to export VTK data (for e.g. paraview),
analyze fracture propagation etc.
For me, the conclusions are:
* for serious, really high performance things, use ESyS (I will try to
port my concrete constitutive law at some point, which shouldn't be too
difficult). There is no sense trying to parallelize yade to larger
extent than what we have now (shared memory), since it would probably
have to be rewritten completely -- quite wasteful, since ESyS works well
for those cases and it would be a tremendous effort to get it right.
* Yade is much more flexible, therefore a good playground for various
constitutive laws and methods, but with small number of particles.
Couplings are very likely much easier to do with yade, as well as
testing new particle types and so on.
(I am wondering why Frederic started Yade at time when ESyS was already
around for many years -- it seems unlikely he didn't know about it,
since both Yade and ESyS are offsprings of SDEC).
Cheers, Vaclav
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
--
___
Chareyre Bruno
Maître de Conférences
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-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
