yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

On 28/09/14 17:29, Janek Kozicki wrote:
> I only raised this because I think that adding new packages should
> not require editing the stuff in core/ directory. Which is the case
> with chain, SPH and LIQMIGRATION.
To me it means a poor implementation of those, not a need to edit core/.

>
>> Another question is, do QMBody's have to be in O.bodies? 
> definitely, that's where the particles that are part of the
> simulation are stored. Besides, where else would you put them? :)
>
>> It should be the case only if the QM particles are supposed to
>> interact with DEM things.
> It should be the case only if O.bodies are supposed to interact with
> other O.bodies.
O.bodies is de facto composed of DEM objetcs (SPH is the unique
exception and it is experimental, not sure we should use it as an exemple).
Hence if non-DEM objects (and here I was anticipating that interactions
between QM particles and newtonian particles would be nonsense, then not
planned) are to be introduced they could as well go to
O.QMbodies.
I don't see it as a nice move to add some typecasting on State or Body
for one single optional module.
I am not big fan of renaming Body -> DEMBody either. 99.99% of users use
yade for DEM, we will not force them to type DEMBody, DEM is implicit.

> There are similar problems with Material, where I don't need Material::density,
> and with State where I don't need
Materials are shared. So this one is ok.

> State::angMom, State::angVel, State::blockedDOFs,
> State::densityScaling, State::inertia, State::isDamped, State::mass,
> State::vel, State::inertia

This is more a problem indeed.  We should find a way to solve that
without casts.

Bruno