Just tried it out and you are both right. There is almost no speedup.
Thanks,
Klaus
On Tue, 17 Jan 2012 05:55:43 PM Anton Gladky wrote:
> I think, Bruno is right.
> There will unlikely be a speedup. But you can try anyway.
>
> Anton
>
> On Tue, Jan 17, 2012 at 7:23 AM, Klaus Thoeni
wrote:
> >
I think, Bruno is right.
There will unlikely be a speedup. But you can try anyway.
Anton
On Tue, Jan 17, 2012 at 7:23 AM, Klaus Thoeni wrote:
> Hi Bruno,
>
> On Mon, 16 Jan 2012 11:20:57 PM Bruno Chareyre wrote:
>> >> It would work but it would be ugly to include WireMat.hpp in the
>> >> colli
Hi Bruno,
On Mon, 16 Jan 2012 11:20:57 PM Bruno Chareyre wrote:
> >> It would work but it would be ugly to include WireMat.hpp in the
> >> collider's code.
> >
> > I agree but I would need a quick solution.
>
> The the sort of quick solution that you will never commit? Then try it.
> My bet is t
>> It would work but it would be ugly to include WireMat.hpp in the
>> collider's code.
> I agree but I would need a quick solution.
>
The the sort of quick solution that you will never commit? Then try it.
My bet is that, unfortunately, it will not give a very big speedup.
The big task of the col
Hi Bruno,
On Fri, 13 Jan 2012 12:54:20 AM Bruno Chareyre wrote:
> Yes, it is like a deformable clumps.
>
> > Something else I had in mined, the collider could check the material of
> > two bodies and if it is of type WireMat then do nothing. What do you
> > think?
>
> It would work but it would
Yes, it is like a deformable clumps.
> Something else I had in mined, the collider could check the material of two
> bodies and if it is of type WireMat then do nothing. What do you think?
>
It would work but it would be ugly to include WireMat.hpp in the
collider's code.
I'm thinking we could ha
Hi Bruno,
it is purely for speed up! The model already has the functionality in the IP2
functor, so creation of new interaction is omitted. However, I want to avoid
new contact detection since I am running examples with huge meshes (20
particles), and this I guess is Collider related.
And
Klaus, do you ask that for speedup or is it really a functionality problem?
In the later case, you could use the same idea as for setCohesionNow
(https://www.yade-dem.org/doc/yade.wrapper.html?highlight=setcohesionnow#yade.wrapper.Ip2_CohFrictMat_CohFrictMat_CohFrictPhys.setCohesionNow).
The differ
Klaus Thoeni said: (by the date of Wed, 11 Jan 2012 23:50:22 +1100)
> I think one option could be to put all particles of this group on different
> groupMasks. But I have 1000s of particles in this group.
try to change groupMask after interactions are created.
--
Janek Kozicki
Hi Anton,
thanks for your suggestion. Actually I had already a look at the "groupMask"
option. It works fine if you have groups of particle which should interact or
not, as you explain in your example. However, in my case I have three groups
of particle and I want avoid contact detection betwee
Hi Klaus,
one of possible solutions is to use "groupMask', which is bitmask.
For example, you have 3 groups of particles. 1 and 2, 2 and 3 should
interact, otherwise
1 and 3 should not. In this case bitmask can be so written:
16 8 4 2 1
1) 1 0 0 1 0= 17
2) 0 1 0 1 1= 11
3) 0
Hi guys,
I have a tricky question. How can I avoid new contact detection between a
group of particles?
For my WireMP a first create particles which represent the net. Second, I
create a link between particle since particle interact remotely (there is no
physical contact between these particles
12 matches
Mail list logo
