VMD-L Mailing List

From: Thomas C. Bishop (bishop_at_latech.edu)
Date: Wed Jun 26 2013 - 11:19:15 CDT

Thanks JOhn and thanks for the explanation.
The documentation provides all the information I need.

IN short... RTFM..
  "read the fresh manual" is not "read the first manual" :-)

"waitfor all"
works as advertised.

IN some of my scripts I have
"waitfor all" and some "waitfor 1"

so where did "waitfor 1" come from in my scripts?

The "waitfor 1" lines are in my scripts that I developed with the
logfile option to VMD.
which dumps
mol addfile {dyn1.dcd} type {dcd} first 0 last -1 step 1 waitfor 1 0
for default options

clicking "load all at once" in the gui dumps
mol addfile {dyn2.dcd} type {dcd} first 0 last -1 step 1 waitfor -1 0

which gives the "fast load"

There are good reasons to use waitfor 1 in some scripts.
(can't recall any at the moment)

I suspect that the "waitfor" options have changed since I wrote my
first VMD script in circa 1996 :-). I think 1 or 0 used to mean "all"
....RTFM...

Tom

On 06/26/2013 09:26 AM, John Stone wrote:
> Hi,
> If you're loading large trajectories and you want them to load
> rapidly, you should add the "waitfor all" options to the load flags
> so that VMD doesn't alternate between trajectory frame display
> and loading. If you load files with "waitfor all" this allows VMD
> to load them in their entirety at greater efficiency. Using the
> waitfor all flag should also eliminate any differences one sees
> that are the result of the order of file loading. When you loaded
> your trajectory first, that was having the effect of not providing VMD
> with structure info, making the display work "easier" and thus faster,
> but that's still not as fast as skipping the display updates altogether
> with waitfor all. If you use a script that loads files in a loop, you
> would also want to use the waitfor all flags there as well:
>
> foreach i $argv {
> puts "loading $i "
> mol addfile $i type {dcd} waitfor all
> }
>
> If this doesn't resolve the issue, then the next question is what version
> of VMD you are running... :)
>
> Cheers,
> John Stone
> vmd_at_ks.uiuc.edu
>
> On Tue, Jun 25, 2013 at 09:09:53PM +0100, Jonathan Phillips wrote:
>> Hi Tom,
>> I find that if I load my parameter file followed by my dcd, it's much slower then if I load my dcd followed by my parameter file.
>> Don't know why, but getting rid of the '-parm7 vac.parm' bit and adding
>>
>> mol addfile vac.parm type {psf}
>>
>> to the end of the script may just do the trick.
>> Jon Phillips
>>
>>
>> ________________________________________
>> From: owner-vmd-l_at_ks.uiuc.edu [owner-vmd-l_at_ks.uiuc.edu] On Behalf Of Thomas C. Bishop [bishop_at_latech.edu]
>> Sent: 25 June 2013 18:22
>> To: vmd-l_at_ks.uiuc.edu
>> Subject: vmd-l: load speed of dcds
>>
>> Dear VMD.
>>
>> I noticed a major difference in load speeds when reading dcds depending
>> how I call load dcds (factor of 10ish)
>>
>> vmd -parm7 vac.parm dyn[1-5].nowat.dcd
>> will load all five dcds (1000 frames each w/ 23,890atoms, 1.4G) nearly
>> instantly
>>
>> vmd -parm7 vac.parm -dcd dyn1.nowat.dcd -dcd dyn2.nowat.dcd -dcd
>> dyn3.nowat.dcd -dcd dyn4.nowat.dcd -dcd dyn5.nowat.dcd
>>
>> does the same
>>
>> BUT using a script that loops over the file names is very slow
>> (comparatively)
>>
>>
>> vmd -parm7 vac.parm -e ~/bin/load-dcds.vmd -args "dyn[1-5].nowat.dcd"
>> takes a very long time (contents of load-dcd.vmd listed below)
>>
>> I've played w/ the "waitfor" option to the mol addfile
>> and using animate read instead of mol addfile
>> but still could not get same load speed as the initial command line.
>>
>>
>>
>> Any suggestions on how to improve read performance from w/in a "read
>> file loop" would be GREATLY APPRECIATED.
>>
>> Thanks
>> TOm
>>
>>
>>
>>
>> **************************************
>> more ~/bin/load-dcds.vmd
>> foreach i $argv {
>> puts "loadign $i "
>> mol addfile $i type {dcd}
>> }
>>
>>
>>
>>
>>
>>
>> --
>> *******************************
>> Thomas C. Bishop
>> Tel: 318-257-5209
>> Fax: 318-257-3823
>> www.latech.edu/~bishop
>> ********************************
>> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an attachment
>> may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
>>
>>
>>
>>
>