yade-dev team mailing list archive

[Janek Kozicki <janek_listy@xxxxx>]

Bruno Chareyre said:     (by the date of Mon, 29 Sep 2014 11:29:20 +0200)

> 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/.

ok. So the should be moved. That will solve my problem.

> >> 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 are to be introduced they could as well go to
> O.QMbodies.

Maybe you are right, but that will mean adding a new BodyContainer
attribute to Scene. I think that doing this for the sole purpose of
separating DEM and QM is a little superfluous. And then another
attribute for QMInteractions?

I think that current design works well. In fact exceptionally well,
thanks to all those Functors 1D and 2D that handle all automatic
dispatching, and thanks to Vaclav's hard work on polishing this
approach with all those macros. If there is no functor to handle QM
and DEM interaction - then it cannot occur. That's how it works
currently, and I like it.

However let's first see how it works, when I'm done implementing the
first version.

> (and here I was anticipating that interactions
> between QM particles and newtonian particles would be nonsense, then not
> planned)

that's mostly correct. There are some advanced multi-scale type
simulations that calculate molecules insides (electrons) using
quantum mechanics, and molecules outsides using classical mechanics
(collisions between molecules). But I am not going in this direction.
At least not for now.

> 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.

About Body: You already said that those three (chain, SPH and
LIQMIGRATION) are a poor implementation mistake. This makes me 100%
happy and I withdraw my proposal to create DEMBody and QMBody.
Instead I will help in cleaning Body class. So we are in full
agreement here ;)

About State and Material see below.

> > 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.

Do you mean it would be ok to move Material::density to some derived
class, or by "ok" you meant something else?

> > 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.

I assume that by word "casts" you mean "inheritance" and "derived classes" ?

As I said I can live with those extra attributes. They just waste
memory, and do not hurt.

I hope that I will come up with a solution that would be compatible
with all currently written yade scripts. I was thinking about making
StateEmpty right above State. But I don't know now if it would work.
Maybe some of those attributes are used in some places that will make
this approach not possible. We will see :)

best regards
-- 
Janek Kozicki                               http://janek.kozicki.pl/  |