← Back to team overview

yade-dev team mailing list archive

Re: Enriching GLobaleEngine hierarchy

 

>         
> I think it is the definition of PartialEngine that has to be stated
> clearly. Actually, I found this definition in ForceEngine where it
> says that a PartialEngine should act only on some bodies modyfing
> velocity, position and so on. This definition can obviously lead to
> some misunderstanding (as pointed out by Jerome) since, for instance,
> TriaxialStressController is actually working only on certain bodies in
> the simulation.That said, perhaps we should find a different
> definition for PartialEngine. Or simply create new blocks of Engines
> as rightly proposed by Vaclav.

I was taking PartialEngine defined by its class interface:
subscribedBodies (i.e. single list of bodies it acts on), which is not
used by Triaxial*, Kinem* etc etc.


> BTW, we have a couple of folders (I think, since I am not properly
> using the last release), one called GlobalEngine and another one
> called PartialEngine inside /pkg/dem/Engine. What is here the
> meaningful of the distinction? It is just to know for future
> commitments.
(we need both commits and commitment from people, right! :-) )
>  For instance in /pkg/dem/meta folder I see ViscoelasticPM files that
> is a contact law, and in /pgk/dem/Engine/GlobalEngine other contact
> laws, like CohesionlessMomentRotation. Which folder should go a
> contact law into? With a contact law, I mean not only the law functor
> lonely but say a collection of classes like in ViscoelasticPM or
> HertzMindlin.  
Historical structure mostly. I created the "meta" directory back then
for files comprising more things than just one type of thing (ConcretePM
and those you mention as well). For me, I could imagine having just flat
directory pkg/dem/*.cpp (same for pkg/common etc), as I use exclusively
tags to nagivate through the structure anyway, almost never actual
filenames.

v.




Follow ups

References