yade-users team mailing list archive

[Janek Kozicki <janek_listy@xxxxx>]

> Oh! I forgot to mention one thing : Each wall (ok, I will use 6 walls
> rather than one box...)

using 1 box is an interesting idea. Currently it is not possible, since you
would need 1 box with swapped inside/outside. If you generated a
simulation where you have 1 box, filled with spheres inside, it would all
totally explode, because spheres would behave is if they were INSIDE a
solid box.

However creating another kind of box, with swapped inside/outside should
be possible. Not sure how to do it now - I would need to think a little
bit about that. But it's a very interesting idea, so I think that sooner
or later we will return to it, to implement it. Maybe that class could
be called AntiBox :)

> must know the total stiffness K, where K is the sum of stiffnesses over
> all interactions of type wall-something. Based on K, I can assign the
> wall a displacement such that the force on it reaches the presribed
> value in only one time-step (I hope this explanation is clear...).

I get it.

> So : I will have to iterate over all interactions in the engines (6
> walls => 6 iterations over all interactions!) or modify something
> somewhere to increment K. From your previous answer, I realized that
> ElasticContactLaw is not the best place for this since it does not check
> the type of bodies. However, highest level functions (functions that
> know if one body is a wall) are not supposed to know the stiffness of
> elastic contacts... are they?

hmm... I'm thinking about it and I see one solution.

1. add another class derived from PhysicalAction. currently we have classes
Force and Momentum. let's call this class Stiffness. it will be stored in 

MetaBody::shared_ptr<PhysicalActionContainer>	actionParameters;

along with Force and Momentum. To have class Stiffness working properly
it must be added in SDECTriaxialTest::createActors() to
actionParameterInitializer.

(yeah I will rename actionParameters to physicalActions, but now I'm not
sure if PhysicalAction is a good name?! because Stiffness is not really
a "physical action", but oh well ... choosing a good name for a class in
C++ programming is a *very* difficult task - if you have any suggestions
- you are welcome. I'll avoid too much sudden name changes, because it
will confuse everybody).

2. then we must add another StandAloneEngine, let's call it
StiffnessCounter (or you can pick up any other name if you feel that you
have something better). This engine should be executed after
ElasticContactLaw (I mean - added to SDECTriaxialTest::createActors() ),
and it will iterate ONCE through all interactions, and add Stiffness
vaules to corresponding places in physicalActionContainer. Just like
ElasticContactLaw is doing with Force and Momentum. First (simplest
approach) will add Stiffness without checking whether it is a sphere or
a wall, so all spheres will also have their total contact stiffness
summed, not only the walls. To filter walls from spheres - we can think
about it later (it is possible, but doing too much at once only makes
things more complicated). That StiffnessCounter will be in fact quite
short - maybe 40 lines of code. And you can copy/paste for(;;) loop, and
declaration of ::iterator from ElasticContactLaw.

3. once you have Stiffness in physicalActionContainer - you can access
it from you DeuxEx just like you can access Force.

this was a brief explanation of the idea which I have in mind. tell me
if you understand it :) I feel a small temptation to do it myself,
because it's interesting. But I have also other work to do (lattice and
documentation). Maybe I will, but before I will - you can try, and I
will not resist the temptation to help you :)

you can add all the classes (and directories) in -package-dem, and it is
easier to modify .pro files by hand (for example with F4 from mc), than
to edit them with kdevelop3. (kdevelop3 displays scopes in a weird
manner, so better ignore it - I hope that they will fix this in near
future).

and honestly I'm still not sure if this is the best solution :) It's the
obvious one. Maybe there is something better, which will came up later.

As a general rule - when you work with yade - it is better to add new
classess than to modify existing ones :) (exception here is only a
FileGenerator, which is currently intended to be modified very often,
but hopefully later we will fix this problem ;)


> "Error: Could not open /dev/nvidiactl because the permissions
> I know how to solve it temporarily (chmod on OGL files each time I start a KDE session). 
>>> I just change
>>> /nvidia*:root:video:0660
>>> /
>>> to
>>> /nvidia*:root:video:0666/
>>> in udev.permissions. It should fix the problem (I did not check yet).
> Do you have an idea if this may be due to Yade?!

your fix works, but I smell trouble - I'd prefer to check - because
maybe it's a problem with yade, not with nvidia.

Please do following:

1. make sure that YOU are in the group 'video'. To check that type in
the terminal a command 'id', if not - then type as root 'adduser yourlogin video'
2. change back udev.permissions to previous (non-working) state
3. download latest SVN version of yade.
4. copy old version of file OpenGLWrapper.hpp (from yade-all-0.9.0.911 release)
from yade-lib-opengl/src to corresponding place in latest SVN checkout.
5. compile and try to run (make sure that you are not running as root!,
type 'whoami' to check that). tell me if you still got that "Error:
Could not open /dev/nvidiactl"

(it is possible that only steps 1,2,3,5 are sufficient, and then -
OpenGLWrapper.hpp is OK)

It would be useful for me if you check that, because I made in
OpenGLWrapper.hpp one change that _fixed_ a similar problem on gentoo.
It is possible that this change has broken the same thing on your
computer.

> More generally, do you recommend installing Yade after a complete
> checkout; or is it better to install it from the "official" (but very
> old ;)) version of Yade-all and update specific parts one by one?

it is better if you use latest SVN checkout, and please do not update
specific parts by mixing release with latest svn - this will not work -
I have done too much changes.

> Is the trunk version stable currently? 

it's all in beta stage :) So - nothing is stable. But it is all
compiling and working. When I commit changes to SVN I always verify that
it will be compiling and working. And if I discover any problem with
latest SVN - I'm committing few hours later a fix.

so in general it is better if you use SVN.

I don't know when there will be a new release. For now - I want to
release documentation, and then make another release of yade.

-- 
Janek Kozicki                                                         |
_______________________________________________
Yade-users mailing list
Yade-users@xxxxxxxxxxxxxxxx
http://lists.berlios.de/mailman/listinfo/yade-users