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