yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

Hi,

> Even if it were not the case, you
> know that cooperation is difficult, due to both technical (difficult to
> communicate, lack of documentation and derivations of formulas for other
> people to understand) and personal (everybody has his/her own piece of
> code and doesn't like other to touch it, for the fear of others breaking
> it) reasons -- look at PeriIsoCompressor/PeriTriaxController/Peri3dController,
> discussion in Grenoble, read recent e-mails on dynCell & mass: it just
> costs too much energy, which is a scarce resource.

I think I'll keep inviting everyone to take advantage of, and improve,
what is already implemented. If some of them prefer a different way,
well, that's ok. Don't hesitate to tell if you'd prefer to see commits
to separate versions for some classes.
I thought PeriTriaxController, and more generally periodicity, were good
examples of constructive cooperation : dynCell control, disp/vel
scaling, were added functionalities in existing code. Maybe you think
homothetic resize is "not consistent"? I'm wondering now.

I understand it can be more fun to rediscover everything on your own.
Consistently, I should perhaps not interfeer when you think
relSpin=spin2-spin1 is inconsistent, plastic dissipation is wrong,
loading rate control is comparing apples and oranges, etc. I'd just ask
you to not claim such things to loud on the list (except if it concerns
your own code ofc) as it can mislead others.

>> Periodic velocity shift (Vincent told me it was so tricky that nobody
>> would have been implemented it yet), plasticity, and other things, are
>> already in Yade. It would be a pitty to derive everything again.
> When you say that they are "in Yade", what does it mean?

It means anyone can run yade simulations in periodic boundary conditions
with correct velocity shifts. There will be no surprise.
The simulation will be stable and reproducible, energy will be
conserved, the results will be in line with previously published DEM
results.

> Yade is a
> toolkit of pieces, some of them fit together, some don't. Everybody is
> working on his own part anyway and I don't think there is (for good or
> bad) some substantial convergence. I see Yade now more as software
> platform (which provides things like data persistence, python bridge,
> gui, 3d, math libs, the functors/dispatchers framework and a few common
> engines like the intergrator or collider), not necessarily as a complete
> DEM solution. Of course the question is what hold the whole code
> together then (I don't see anything).

This is quite depreciating. Even if Yade is a very nice toolkit, it is
_also_
really a complete DEM solution. Out of the box, it offers more than PFC
(GUI, scripting, variety of validated contact laws and boundary
conditions, set of predefined simulations).
End-user applications are something that hold (or should hold) the
pieces together, and they are why people download Yade in the end. For
somebody disregarding applications, it is indeed tempting to see only a
collection of almost useless small things.

Cheers.

Bruno