Indeed, my fault. I forgot to change some of the ElastMat to FrictMat in the
declaration. Strange that there was no error during compiling. It's working
fine now.
Thanks a lot
Klaus
On Tue, 1 Mar 2011 11:55:49 pm Bruno Chareyre wrote:
> > Tried to inherit WireMat from FrictMat and using
> >
Oh? ok. In the script you sent, it is not active (verletDist is negative
by default). By making it 0.3 radius, I can get down to 1 each 10
iterations.
But from documentation:
"Negative value will trigger automatic computation, so that the real
value will be |verletDist| × minimum spherical
Hi, guys,
I think we should try to parallelize insertionsortcollider a little
bit and then measure productivity again. But not to brake the code, it
is better to do in separate branch, I think.
Anton
On Tue, Mar 1, 2011 at 9:31 PM, Sergei D. wrote:
>
>> Oh? ok. In the script you sent, it is
Oh? ok. In the script you sent, it is not active (verletDist is negative
by default). By making it 0.3 radius, I can get down to 1 each 10
iterations.
But from documentation:
"Negative value will trigger automatic computation, so that the real
value will be |verletDist| × minimum spherical p
This is because the simulation is dynamic AND you don't use collider's
Verlet distance.
No, I use Verlet. Is is enabled dy default. The collider run each 2
iteration.
Yes, it is because dynamic, and the current collider is bad for that
cases...
--
Best regards,
Sergei D.
Hi Sergei,
This is because the simulation is dynamic AND you don't use collider's
Verlet distance.
In triaxial test (quasistatic), the collider run only each 100
itérations or even less, which makes its cost negligeable vs.
interaction dispatching.
Even in the dynamic case, you should use Verlet d
Hi,
I think that:
(1) if you consider the negative/positive force decomposition, so the negative
viscous forces are to be taken into account like any other negative force. So
just test the sign and it's ok (in my opinion, but it depends on why you want
to do this decomposition)
(2) if you cons
Hi!
I did a perfomance test for parallel mode and results in no good.
Performance boost only about 40% from 1 thread to 4 thread for 200k
particles...
Cause is a non-parallelised InsertionSortCollider, who need about 80%
time with 4 threads.
Results attached.
--
Best regards,
Sergei Dorofeen
> Tried to inherit WireMat from FrictMat and using
> Ip2_FrictMat_FrictMat_FrictPhys()
> Law2_ScGeom_FrictPhys_CundallStrack()
>
> but got this:
>
> terminate called after throwing an instance of 'std::runtime_error'
> what(): Undefined or ambiguous IPhys dispatch for types FrictMat and
> Wire
Ok, then I would have a new question for you. I was thinking to apply
Vincent's suggestion to plot fabric tensor considered as the sum of two
contributions (which is already in code), one due to negative forces and the
other to positive ones. The distinction could be made if one uses cohesive
conta
revno: 2775
committer: Anton Gladky
branch nick: yade
timestamp: Tue 2011-03-01 11:31:54 +0100
message:
"mask" parameter is added to GravitiEngines to make it more flexible.
modified:
pkg/common/GravityEngines.cpp
pkg/common/Gravit
revno: 2774
committer: Anton Gladky
branch nick: yade
timestamp: Tue 2011-03-01 10:45:24 +0100
message:
Fix formula displaying in utils.getViscoelasticFromSpheresInteraction
modified:
py/_utils.cpp
--
lp:yade
https://code.launchpad
Ok, I think I know why now. I mean, since I have viscous forces stored into
normalForce that could be the cause.
Cheers. Chiara
On 28 February 2011 21:02, Chiara Modenese wrote:
> Hi Guys,
>
> small question. I was trying to plot normal force versus overlapping of all
> my interactions. For the
On 1 March 2011 01:24, luc scholtes wrote:
> Hi there,
>
> I was looking for a way to compute stress in a given subdomain and just
> found this thread :-)
>
> My purpose is to have a look at the respective distribution of normal (Sii)
> and shear (Sij) stress components in my cohesive assemblies.
14 matches
Mail list logo
