yade-dev team mailing list archive

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

> Yeah, when I say nothing it means I'm happy. All this is perfect 
> usage of pointers. One question I have in mind is if many bodies 
> with the same material pointer would slow down the parallel runs,
> but whatever the answer we can use per-body props, so everything 
> is ok.
I think I was talking nonsense at that point. There is no degradation if
that part of memory is not _written_ by many threads simultaneously.
Quite on the contrary, if there is less memory to be read, there is more
chance that when other thread needs it, it is already in some of the
processor's cache.

> >All this should lead to shared interaction properties (if desired). You
> >can always have fancy InteractionPhysics functor, that will assign
> >interaction properties based on phase of the moon or GroupRelationData,
> >this will not prevent you from being flexible.
> 
> I still don't understand the point of shared InteractionPhysics. 
> So many efforts just to avoid duplicating values of the friction?! 
> Come on guys, just give up. (and what about parallel access to props,
> which will be a lot more frequent than access to bodies props?)

See above for parallel. For me, the extension to shared interaction
properties... is not so important, frankly speaking; ATM I have most
constant and global interaction parameters in the engine
Law2_Dem3DofGeom_CpmPhys_Cpm (yieldSurfType, yieldLogSpeed,
yieldEllipseShift, omegaThreshold, epsSoft, relKnSoft), which are the
same for all interactions. I didn't want to define them in the
InteractionPhysics functor and pass them and store them in all
interactions individually. It doesn't feel exactly right to have it like
this. True, not a pressing issue for me, but seemed that it was what
Vincent was up to with GroupRelationData.

V.