yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

Janek Kozicki a écrit :

>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? 
>
Well no... the first run is the one that is almost always wrong. The 
next ones are usually correct, probably because they start with the 
timestep from the previous run, which is correct.

>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.
>
>  
>
Ok ok, I know that you have something else to do now :). I just wanted 
to point out the problems.

> 
>  
>
>>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.
>  
>
Yeah I remember that you made changes in order to save time in nullgui runs.

My "old" version is r980 i think (not sure how to check the revision 
number...  kdesvn displays different revision numbers for different 
parts of Yade, r980 is the most recent "last changed revison" i can see 
in kdesvn.)
The "recent" version is r1030.
Both versions are compiled in debug mode.

I've played a bit with the synchronization options and in fact i have 
obtained faster runs with r1030 _sometimes_ (3000it/min with r980 vs 
4000it/min with r1030). This is good news.

The problem is I can't really reproduce any behaviour.

Here is one of the sequence in my experiments :

-I start Yade, load a xml, click on play, it explodes.
-I click stop and play again, it doesn't explode. The computation is 
slow (300 it/min) and the rendering is not smooth.
-I go check the refresh rate, it's at 20ms, very small!, so I set it to 
120ms and press the little arrow that is in on the right side of the 
refresh rate to continue the simulation (the synchronize option is 
always disabled here).
-Now it computes fast (4000it/min) and the rendering is smooth.
-But if I click on the little arrow again (or even on the main "play" 
button) without modifying any field, the speed of computation will 
change... it can go back to 300it/min or even lower.

Also strange : sometimes it seems that the refresh rate of digits in the 
time part is uncoupled with the refresh rate of the QGL window (you can 
see the number of iterations iterating very fast, while the rendering 
display only few frames per sec.). And sometimes they look coupled (you 
have time to read all the digits because not all number of iterations 
will be displayed it makes like 10, 67, 124, 413...).

Ok, I just found something I can reproduce :
It looks like the default value of the refresh rate is 20ms when you 
start Yade, is it true?
With this value, the computation will always be very slow during the 
first run (well at least I checked 5 times and I had like 300it/min or 
less each time).  And even if I change it, the 20ms will be back when I 
restart Yade.

I'm sorry, not sure these experiments help a lot...
I think Vaclav is now looking what the "play" button actually do. I 
wonder what happens if you Janek click on "play" many times?

Bruno 




>
>(*) 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' ?
>
>
>  
>


-- 
_______________
Chareyre Bruno
Maître de conférence

Institut National Polytechnique de Grenoble
Laboratoire 3S (Soils Solids Structures) - bureau I08
BP 53 - 38041, Grenoble cedex 9 - France     
Tél : 04.56.52.86.21
________________

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