yade-dev team mailing list archive

[Janek Kozicki <cosurgi@xxxxxxxxx>]

Bruno Chareyre said:     (by the date of Tue, 19 Dec 2006 21:38:30 +0100)

> Ok, I compiled this and it works :) (or it looks like). Tanks a lot Vaclav.
> 
> Two other points :
> 1- I still need to click "stop" before "play" or the sample will explode 
> (probably the time step set to an unknown value...). Its in fact an old 
> problem with omega if I remember well. As a quick solution : is it 
> possible to implement an auto-click on "stop" when a xml is loaded? ;)
> This problem scares me a lot as I never know what will happen when I'll 
> start the computation with nullgui... (for the moment it looks like it 
> works but...)

The *first* run in QtGUI works OK, right? Then in NullGUI there is
always only *first* run. So in NullGUI it must work too. Yes in the
subsequent runs the timestep is not recalculated, this should be easy
to fix :) I hadn't fixed this so far, because I'm usually using
NullGUI for calculations :)

I'm not sure if I'll be able to look at this now. At least I want to
wait for debian package with wm3, Artur is working on that :) So I'll
avoid installing wm3 by hand, but use his package. Then I'll have a
look at this.


 
> 2- It appeared that slow execution was not linked with the segfault 
> fixed in r1030. As Vaclav showed to me, it's the rendering that is now 
> very slow. I can run 2 versions of Yade, one is old and have a fast 
> rendering, the other one is the last SVN snapshot (Vaclav remember to 
> remove lines 12,15,16  in yadeWm3Extra.cpp...) and have a VERY slow 
> rendering.  This is not a critical bug, but this 3D rendering is really 
> usefull for developping something like the triaxial test or the 
> capillary law and seeing what happens, and it is beautifull :). So what 
> happened to the 3D rendering?


Please give more information about slow rendering. I have made
special effor to make it faster(*) than in last yade release. And it
*is* faster on my computer. But I'm using a bit older version -
without Vaclav's changes.

Which SVN revision is fast. And which is slow? Then maybe we can find
what commit introduced the slowdown.


(*) I have made two separate threads - one for calculation, another
for drawing. Because of that on two-precessor computer the speed of
QtGUI is the same as NullGUI, because drawing is done by second
preocessor. On single-processor machine QtGUI is slower than
NullGUI (because of drawing) and has the same speed as QtGUI in older
yade versions, before those changes. With this two-thread method picture
is drawn when every N miliseconds, where you can configure 'N' in
simulation controller (on the bottom, there is a spinbox). Previously
it was calc-draw-calc-draw. Now it can be:
calc-calc-calc-ca(draw)lc-calc-calc-cal(draw)c-calc-....

Also you can click 'synchronise' and then you have:
calc(N ms)-draw-calc(N ms)-draw. So it's nearly old behaviur, except
that if calculation is faster than N ms then draw waits until full
N ms passes from previous drawing. If it's longer than N ms then it
doesn't wait and draws immediatly after calculation is finished. The
minium value for N is 20 miliseconds.

So I do not recommed 'synchronise' for regular use. I can be only
useful when you want to watch with your eye what's happening between
iterations. 20ms is 50 frames(iterations) per second, a border speed
that human eye can recognise.

Sure that 20ms limitation could be removed, maybe Andrzej Oszer will
work on that, as he plans to work on parallel stuff anyway. I
introduces it because it was easier for me to implement, and because
intention of 'synchronise' is to be used only when you want to see
every iteration and don't miss anything. In fact I used it often with
lattice model, but with delay 120ms, otherwise the things were
happening too fast to see them :)


Also you should check if you have still working correctly 3D hardware
acceleration.


Ok. So check what SVN rewision is fast and which is slow. And then it
will be possible to locate the source of this problem. 


 
> BTW, it looks like I can't connect to the IRC from my office. It would 
> be a good thing though...

hmm.. maybe you can try with 'gaim' ?


-- 
# Janek Kozicki
_______________________________________________
yade-dev mailing list
yade-dev@xxxxxxxxxxxxxxxx
https://lists.berlios.de/mailman/listinfo/yade-dev