yade-dev team mailing list archive

[Vincent Richefeu <richefeu@xxxxxxxxxxxxxxx>]

Le 15 juil. 09 à 17:01, Václav Šmilauer a écrit :

> > 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.

Ah ok! I have misunderstood this aspect and I though that groupMask  
was a simple int number.
I will not use it here anymore. Sorry.

> What happens if the mask is 3, for instance (i.e. 0b00011),
> which column/row of GroupRelationData you will use?

An interaction implies two bodies, so two groupMasks (or groupId, or  
materialId). So there is no problem with GroupRelationData:
We could accede a parameter (say 'par1') like this :
par1 = groupRelData->getParameter("par1", bdy1->materialId, bdy2- 
>materialId);
(Note that it should also work if materialId was a field of bit)

> 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.

Maybe our misunderstanding comes from the fact that I'm simple- 
minded. For me, rigid bodies have no material properties (no young,  
no poisson, no...) because they are rigid. If they were not, Newton's  
law could not be applied at the body centers. So I don't need  
'material' properties but 'interaction' properties (that can depends  
on the materials). The solution proposed in yade (and also the  
current solution) is nice, but I would like to use  also my basic  
solution with a simple and easy-to-use implantation.

Actually, you proposal solve my problem (and I thank you for your  
patience), but I would use it like this:
mat0 = NoMaterial() # I just need an identifier
mat1 = NoMaterial()
O.mats.append([mat0 mat1])

A simple unsigned int (groupId) should be sufficient.

> 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

Your right! Phase of the moon can act on the shape of liquid bonds  
between soil particles! ;)

Vincent