@Bruno: O is defined a a global variable but it is just a convention. If
you continued:
bla = Omega()
bla is O # False
bla == O # False
bla.engines == O.engines # True :-)
# probably some consequence of defining Omega as singleton in C++ (the C++
object is the same but Python object wrapping it
Hi Bruno,
I think the two-step solution is right as far as I can see.
For the performance, I apologize for my incorrect statement; you're
right about this. The logic is a bit different in Woo
(https://github.com/eudoxos/woodem/blob/master/pkg/dem/ContactLoop.cpp)
and I will check again what is
@Vaclav
I removed this functor caching, since it does not seem to bring any benefit
performance-wise.
IIRC the change [1] gave a significant (clearly measurable) speedup.
Before the change it was like this:
if (noIGfuntor || noIPfunctor) assignIGfunctor();
if (!IGfunctor.go()) continue;
bla=Omega()
bla.engines?
Docstring: [...] accessed using O.engines
Do you see the problem? Do I really access the engines of bla as
O.engines?
For some reason the answer is actually yes, haha.
But I guess you will get the general idea.
B
This situation is partly described in [2]. I used it just in a special case:
- spheres with CpmMat
- facets with FrictMat
- Ig2_Facet_Sphere
- Ip2_FrictMat_CpmMat
so Ig2 always order the particles with different shapes in order
Facet-Sphere, so the materials are also ordered FrictMat-CpmMat
I don't understand this assert either.
Just adding more questions:
-Can the same problem also appear in Ip2_FrictMat_CpmMat_FrictPhys?
-This one requires that mat1 is Frict and Mat2 is Cpm, how can it be always
true? [4]
The good fix would be to let materials be swapped, I don't believe it
6 matches
Mail list logo
