← Back to team overview

yade-dev team mailing list archive

Re: Call for brainstorming and re-design / capillary models issue

 

On 26/06/15 10:04, Anton Gladky wrote:
> Hi all,
>
> my 2Cts. I think we should avoid an additional loop in any case.
> It will hurt the calculation speed drastically.
>
> Most of capillary laws implemented by me are more-less "independent" [1]
> and can theoretically be used as external static functions, which are
> calculating just an additional adhesive force.
The problem is if someone want to use those adhesive forces combined
with Hertz contacts, he can't.
It would need to implement a new law functor.

> I think first of all we should finish migration into Python3 and Qt5, because
> it can happen, that Yade will not be able to be compiled on new
> systems soon.
Of course, but I feel useless here. :)

Bruno


> [1] https://github.com/yade/trunk/blob/master/pkg/dem/ViscoelasticCapillarPM.cpp#L219
>
> Best regards
>
> Anton
>
>
> 2015-06-24 10:18 GMT+02:00 François <francois.kneib@xxxxxxxxx>:
>> Hi all,
>>
>> I totally agree with you, this kind of flexibility would be very helpful.
>> In the same fashion (but independently of this issue), if you want a contact
>> between a Sphere and a GridConnection, the force on the GridConnection have
>> to be dispatched on the two GridNodes in the contact law. It means that also
>> you want a simple elasto-frictional law you currently have to copy the
>> existing law (designed for two-bodies-contact) into a new one that just
>> apply the force differently (on three bodies).
>>
>>> I am thinking that maybe allowing dispatcher to call not just the
>>> first one class that matches, but all of them (that were setup
>>> beforehand inside O.engines InteractionLoop), could solve the problem?
>>>
>>> You are absolutely right.
>>> In this case it still needs to workout a model for data classes.
>>> Multiple inheritance maybe? But it may generate ambiguities:
>>>
>>> class ViscElCapPhys : public ViscElPhys, public CapPhys {
>>> ...
>>> REGISTER_CLASS_INDEX(ViscElCapPhys, ??????)
>>> };
>>
>> The idea is good, do you agree that this "multiple dispatcher calls" design
>> should only occur on this particular capillary physics ? Otherwise I'm
>> afraid that this could be a nightmare for simulations with different
>> materials, one inheriting from the other. I have the feeling that a more
>> generic and configurable way exists, allowing the user to define which are
>> the multiple contact physics and law he wants. For example (but maybe weird
>> and painful to develop), multiple materials per body, allowing multiple
>> interactions ? (a classical elasto-frictional one and a capillary one for
>> example)
>> For both solutions, it looks like we have to consider either multiple
>> interactions between two objects, or multiple physics per interaction.
>>
>> François.
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev
> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp


-- 
_______________
Bruno Chareyre
Associate Professor
ENSE³ - Grenoble INP
Lab. 3SR
BP 53
38041 Grenoble cedex 9
Tél : +33 4 56 52 86 21
Fax : +33 4 76 82 70 43
________________




References