yade-dev team mailing list archive

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

> As I said before, the solution described here before seems to be nice  
> (although the question of random-values dispatching remains, cf.  
> Bruno's comments).

As written, cf. http://yade.wikia.com/wiki/SharedMaterialProperties, it
is enhanced in such way that Bruno can be happy (material can be either
shared or per-body).

> When I designed the GroupRelationData (which is very basic), I  
> decided to select the properties as a function of groupMasks  
> combination instead of Materials combination. I did this choice  
> precisely because the interaction parameters can be set depending on  
> the bodies shape, material, surface state, role (driven wall or  
> sample element), etc.
> I'd like to keep this flexibility.

We are using masks for too many things, it seems. I use it as
interaction masks (which works quite well), but you stretch it perhaps
too far. What happens if the mask is 3, for instance (i.e. 0b00011),
which column/row of GroupRelationData you will use?

The same as you use groupMask now (which is supposed to be [bit]_mask_,
not a number), you could use any materialId for any particular body.
Something along these lines:

mat0=ElasticMaterial(young=30e9,...)
mat1=mat0.clone()
O.mats.append([mat0,mat1]) # here materials get their ids; #0 has same properties as #1, but different id

This way, the second material would be the same (cloned), except for
having different Id. Does it solve your problem? I am not able to see
another better solution now.

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.

Vaclav