yade-dev team mailing list archive

[Václav Šmilauer <eudoxos@xxxxxxxx>]

> Today, I found myself trying to get velocities of interacting body1 and 
> body2(*), and I realized I couldn't make it, because the metabody is not 
> a parameter of InteractionGeometryEngineUnit::go().
> 
> Does someone have a simple solution in mind?
> 
> Does the new class "state" affect this problem (will we pass "state" to 
> IGUnits?)? I feel like it will, but I still need a solution without 
> "state" because the Yade/snow code Alsidqi is working with has not been 
> updated for a while and will not be updated anytime soon (yes, I know...).

We might pass 2 x State* instead of 2 x Se3r to the functor, no problem
at all. It would make sense, since e.g. incremental shear could be
pre-computed there, instead of in the constitutive law. Agree?

> I can't explain why metabody is a parameter of many functions in Yade. 
> All engines should be able to access the simulation they belong to, 
> since they can't belong to two simulations at the same time.

Right, but... (in python, you could quite easily make engine belonging
to 2 simulations, though it clearly not what is intended)

> So why do we pass this "ncb"  all the time to, e.g., 
> NewtonsDampedLaw::action(MetaBody * ncb)?

Better suggestion where to store it? In the engine?

> On the other hand, why was it decided that ncb would not be passed to 
> IGEngineUnits, but that Se3's, InteractingGeometries, and the 
> interaction itself would be given instead? I mean,the metabody and the 
> interaction would have been enough to access anything (Se3, IGeom., and 
> a lot more, like the velocities I need now). Is there a benefit for 
> parallelization for instance?

I think it has benefits from memory-access perspective (you eliminate
dereferencing many pointers, i.e.
MetaBody->BodyContainer->Body->State.position instead of se3.position).

Plus restricts what the functor is allowed to do: you shouldn't access
simulation globally from withing constitutive law, for instance, as it
might run in parallel with other constitutive law doing the same. That's
why there is mutex in Body::State you must lock if you write it (e.g.
pkg/dem/meta/ConcretePM.cpp:204).

Functors are function objects, they receive only a few arguments and
compute simple result (contrary to real engines, that operate at the
simulation level). Making the disctiction is quite good, I think.

>  
> (*) The precise reason is we want to rotate the normal based on the 
> movement of interacting bodies, instead of just positions
> and rotations as in other engines. It can be done in the constitutive 
> law to, but the it makes more sense to do that in the GeometryEngine, 
> since the contact law is usually using the updated normal to define the 
> rotation of the local coordinate system.

Exactly; as I said above. I will change the prototype today.