> 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. _______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
