VMD-L Mailing List

From: Norman Geist (norman.geist_at_uni-greifswald.de)
Date: Tue Feb 04 2014 - 06:40:26 CST

Hello people,

 

just wanted to tell that I've found out what is so slow in sscache. It's the
program call itself which is increasing for some reason the more memory VMD
is using, in any case every "exec" takes about a second approximately just
to start running STRIDE which usually finishes instantly. So the time spend
by sscache is just waiting for TCL's "exec" to actually start the
executable. I also checked if it has something to do with environment pathes
etc but I guess the problem is lying deep in TCL. So I just changed the
sscache code a little so it will write out a bunch of frame pdbs and call
stride for all the pdbs in only one exec instance. Unfortunately I had also
to implement the parsing of the output again.

 

So for now I have a sscache implementation that is 100 to 1000 times faster,
depending on SSCACHEBUNCH which is the global variable that controls the
number of frames computed at once. So while playing the trajectory the 1st
time, sscache will run few seconds for frame 0 and play smoothly the next
SSCACHEBUNCH frames.

 

If someone is interested I'd like to share the code. It's also compatible
with REMD.

 

Best wishes

 

Norman Geist