← Back to team overview

yade-users team mailing list archive

Re: Re : Triaxial Test


Bruno Chareyre said:     (by the date of Tue, 29 Nov 2005 12:51:59 +0100)

> Ok, I see : in fact it uses 6 boxes...
> There is a simpler way to represent a wall-boudary : a finite or 
> infinite plane, no need to assign it mass/thickness, stiffness is 
> enough. I had almost the same idea when I thought to _*one*_ box for the 
> triax.
> I will probably implement one of the two solutions (if not both) in the 
> future.

Yes, classes Plane or InfinitePlane are also missing. If you want to
make any of them - it would be really nice. Remember that whatever you
do - I'll gladly add it to SVN repository, so that all other people can
benefit from you work, and - you will have it right here when you
checkout latest yade version :)

to add a Plane you should also add a class InteractingPlane2AABB and
InteractingPlane2InteractingSphere4SpheresContactGeometry, otherwise
yade will be unable to detect collisions between spheres and a plane. To
draw a plane we will need GLDrawPlane and GLDrawInteractingPlane (I can
help with that). So you see - actually adding a new kind of geometry
requires adding several other classess. You can examine the
HollowCylinder example - there I have prepared all the classess needed
to add a hollow cylinder. Adding a Plane or InfinitePlane would be
similar. I have sent it to mailing list:


on the bottom there is a compressed file trunk-HollowCylinder.tar.gz, it
is displayed on the webpage in a way that it is not-downloadable :( But
you should be able to find it in your mail inbox. If not - tell me. I
think that I will put it on the webpage of yade soon, along with other

> In fact the total contact stiffness of a sphere is needed to compute 
> accuretly the critical time-step (Tc).
> I remember I was a bit puzzled when I looked how Tc is currently 
> computed in Yade (but I can't remember exactly). So, perhaps it is not a 
> bad thing after all to compute the total stiffness of spheres. The 
> method I know to evaluate Tc is based on the matrix Mij so that dRi = 
> Mij*Uj (where Ri is the resultant and Uj the displacement of the sphere).

oh! you have shown me Tc in a different light. I havent thought about
that, but you are right. So it means that summing all Stiffness is a
good idea, and after that - I will modify the
ElasticCriterionTimeStepper, to take advantage of that. And yes - I
agree that current method of computing Tc is a mess - it's normal that
before doing something correctly we must first try the same thing in
several different ways :)) When I was writing it I knew that sooner or
later I must come back and clean it :)

> I understand the overall idea, but I am not sure I understand precisely 
> this line (from ForceEngine.cpp) :
> static_cast<Force*>( ncb->actionParameters->find( b->getId() , 
> actionParameterForce->getClassIndex() ).get() )->force += force;

yes, in fact this whole line is too long, and it should be less
complicated. I agree that it must be difficult to comprehend.

I should find some easier way to do the same thing, perhaps some macro..
I'm just not sure how to make it simpler. So until I'll find something -
this is the only way to access PhysicalAction (for example a class
Force, which derives from PhysicalAction)

[1]  static_cast<Force*>
[2]  (
[3]    ncb->actionParameters->find
[4]   ( 
[5]       b->getId() , 
[6]       actionParameterForce->getClassIndex() 
[7]   )
[8]   .get()
[9]  )
[10] ->force 
[11] += force;

[1] static_cast is used to switch between classes which are in the same
inheritance tree. Here the result of static_cast<Force*>(...) is a
pointer to class Force. for example we could write:

PhysicalAction* p =ncb->actionParameters->find(b->getId(),actionParameterForce->getClassIndex()).get();
Force* f = static_cast<Force*>(p);
f->force +=force;

[2] - [9] between the brackets is the single argument for the static_cast :)

[3] retreiving that single argument is little complicated: we find() in
actionParameters a class PhysicalAction that:

[5] corresponds to "the b->getID()" which is id number of a Body. so it
is a PhysicalAction deticated for that Body

[6] and it is also a Force. actionParameterForce is of type
shared_ptr<Force> and we use it ONLY to get the index number of Force.
For example Force has number 1, and Momentum has number 2.

Similar functionality would be provided in following way:

find( b->getId() , "Force" )

it means that you want a PhysicalAction "Force" for this Body. The point
here is that using a string "Force" is tad slower than using a single
number ( getClassIndex() ), which we know that it means "Force".

[4] - [7] arguments for find()

[8] find() actually returns type boost::shared_ptr<PhysicalAction>. That
shared_ptr is a so-called shared pointer. It is an improved version of a
pointer (like for example void* ). Yade is using shared pointers almost
everywhere bacause they are safer to deal with (no memory leaks ;)

so that .get() here is used to extract a normal pointer PhysicalAction*
from shared_ptr<PhysicalAction>

[9] so after all that we have a PhysicalAction*, about which we know -
is of type "Force" because we used getClassIndex() to tell that we
want a "Force" not "Momentum", and not "Stiffness", and now
static_cast<Force*> changes the type of PhysicalAction* to Force*

[10] so if now we have a pointer to class Force* - we can access its member -> force

[11] and do something with it :)

that was difficult to explain, I hope that I succeeded ?

> "F4 from mc" ???!

oops :) I'm talking about midnight commander. you can run it from command
line by typing 'mc', and then you can press F4 (function key) on a file
to edit it.

> In fact it does not apparently :-(.
> I will try what you recommend. But note that the problem is still here 
> after I uninstalled the last version and re-installed the "official 
> release".

oops. strange :( tell me if you find out something more.

Janek Kozicki                                                         |
Yade-users mailing list

Follow ups