yade-dev team mailing list archive
-
yade-dev team
-
Mailing list archive
-
Message #05377
Re: Dem3DOFGeom : ScGeom
Ok, I have just tested it a little bit. I dont see any regressions on speed
calculation. All is ok from that side.
I was talking about one IG, but I did say nothing about merging, sorry for
misunderstanding.
So, it is ok for me now.
______________________________
Anton Gladkyy
2010/7/15 Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>
>
> Suppose sphere and facet in contact, where the facet rotates along axis
>> parallel to the contact normal, so that the contact circumscribes a
>> circle around the facet's rotation center -- will that work?
>>
>>
> Yes, of course. Why not?
>
> So, I revert and resume working with ScGeom as usual?
>>>
>>>
>> Yes, please -- unless you finally say what is the benefit of that
>> change.
>>
>>
>>
> There must have been a misunderstanding at a point. I thought merging
> ScGeom and Dem3Dof was clearly an objective for all of us. Anton asked for
> that once again a few days ago. We discussed that in many mails, and for
> hours in Prague. That is why I didn't elaborate the reason for merging nor
> discussed it in mails before commit, I thought the point was clear. I also
> saw that GenericSphereContact was planned for removal at a point : how would
> it be removed without merging classes?
>
> Do you remember this discussion on precomputing different things in a
> unique geometry class, based on flag saying if the functors are incremental
> or total? You said it would be like emulating inheritance, very true, so I
> thought using inheritance was smarter than emulating it.
> In my vision, ScGeom would precompute displacement for incremental laws in
> contact point paradigm, while Dem3Dof would precompute total strains in
> continuum-discrete paradigm (not fully consistent, since we have in fact 4
> possible combinations with point/continuum vs. incremental/total, but only
> two combinations are in Yade atm).
>
> Actually, I will not try to proove a real need for merging. I did it only
> because I felt it was high in the list of TODOs and I was the assignee (like
> e.g., don't ask me to explain why there is a need to change signs, and why
> me the assignee). From a productivity point of view, having two different
> families of geometry classes and functors in the code is really not a
> problem. I'll be happy with the previous situation.
>
> I need to revert carefully : the same commit contains independant
> improvments and cleanings in ScGeom (bad mistake). I'll see if I can do it
> today, it will be soon anyway.
>
> Bruno
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
> Post to : yade-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
> More help : https://help.launchpad.net/ListHelp
>
References