 |
 |
Hello, Tim says that with 100 residue protein with 100,000 steps this should take no more than a few minutes (with a modern computer). During that time it will take all (well, a lot) of your CPU but the issue here might be that if your computer does not have much memory this would likely result in lots of swapping, which would grind things to a halt as you describe. (The algorithm uses a lot of memory to make it run faster.) So the question is how much memory your computer has and how many other apps are doing something at the same time. If this doesn't make sense or help then get back in touch. Wayne On Wed, 21 May 2008, Tolga Helmbrecht wrote: > Hi, > some Bugs in the Spin System Types Dialog: > > When starting the function there is this warning: > >>> Typing spin systems > Deprecated: getByKey called with too short key > from doLoad line 770 > in /opt/ccpnmr/ccpnmr1.0/python/memops/format/xml/XmlIO.py: > [" obj = oo.getByKey(endMap['class'],useKey)\n"] > Deprecated: getByKey called with too short key > from doLoad line 770 > in /opt/ccpnmr/ccpnmr1.0/python/memops/format/xml/XmlIO.py: > [" obj = oo.getByKey(endMap['class'],useKey)\n"] > > And more important there is an X ressource lockup after some runtime. > During the first steps maybe the first minute, cpu time is mainly on the > python process but quickly Xorg gains a lot. > Later, after some minutes Xorg dominates the scheduler and after some thousand > steps the screen updates very slowly, the step counter jumps some hundreds at > a time after minutes without update and the whole desktop becomes non > responsive because Xorg sticks to 98%. I had the function ran overnight with > the default 100000 steps and I found a completely unusable desktop where > every click took minutes and I had to kill the python from remote, so I can > not tell you how many steps it had finished after 12 hours. > > Tolga >