yade-dev team mailing list archive
-
yade-dev team
-
Mailing list archive
-
Message #02124
Re: ESyS-Particle course impressions
I just want to add, that developers are going to continue and support this
project.
As for me, I will also try Esys for my tasks and will see what is more
suitable. Maybe I will use both.
______________________________
Anton Gladkyy
2009/9/28 Václav Šmilauer <eudoxos@xxxxxxxx>
> 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<https://launchpad.net/%7Eyade-dev>
> Post to : yade-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
> More help : https://help.launchpad.net/ListHelp
>
References