yade-dev team mailing list archive

[Vincent Richefeu <richefeu@xxxxxxxxxxxxxxx>]

> Vincent, to me, the GroupRelationData concept is not very clear. Can I
> have some questions?
>
> 1. Why not have just one table inside, and every engine that needs the
> data could create as much instances as necessary, one for every
> parameter? It would seem more logical than having that inside  
> MetaBody.
> For instance, shared_ptr<GroupRelationData> SomeEngine::kn would hold
> kn's for various groups, kn->getParameter(g1,g2) would get the value.

I do not really understand your solution but I will try to answer  
your question anyway.
When I thought about how to include the GroupRelationData in yade, I  
had the following problem:
"How to access the GroupRelationData from an engine (eg. from  
*Relationships engines)?"
The solution for me was to put it into the MetaBody.
The "good" solution should be the one you propose, but maybe a new  
engine type should be defined in order to hold something like this:
virtual void go (const shared_ptr<GroupRelationData>& grd, const  
shared_ptr<Interaction>& interaction);
(but I have seen in FunctorWrapper that the first argument must be of  
type shared_ptr<YourClass>!)

> 2. Can you provide an example of how is it supposed to be used?

In fact, I use this solution in an other soft. here are some  
explanations: http://gdmtk.wikidot.com/user-data

> 3. The micro-language for serialization doesn't feel like the right
> thing to do. Do you need help with the conversion in
> preProcessAttributes/postProcessAttribues?

Yes, thank you. I will commit my changes soon (It does not work fine  
but it does not interact with existing classes).

> Of couse: It would be nice to have some shared material property class
> (such that I could say: all these spheres have material parameters #1,
> those have #2) -- shared_ptr's could be used for that; or we may add
> MetaBody::materials class that would hold those things.

This is precisely what I wanted to do!
I agree that the class name does not sound good. But the idea is the  
one you describe.
GroupRelationData could be split into 'Materials' that hold  
'SharedMaterialProperty'

> Right now, we
> have material defined separately in every body, along with things that
> differ from body to body (position, damage, ...).

I understand that damage, Young, Poisson... can be held by the  
bodies. But being obliged to assign a friction coefficient to the  
bodies makes me sick!

VR