From: Michael S. Sellers (Cont, ARL/WMRD) (michael.s.sellers.ctr_at_us.army.mil)
Date: Tue Mar 22 2011 - 15:56:17 CDT
Irene,
You might want to experiment with the ASCII format. I'm not sure how
much longer these take to write, or how much larger they are (especially
for 100ns runs), but at least you could aggressively prune them on-site,
download the small(er) trajectory, and maybe narrow down your phenomena
to a time/snapshot window.
Another idea is to just write out restart files and an infrequent DCD
trajectory. Once you find where your phenomena happens, go back and
re-run the simulation from a specific restart point with frequent DCD
writing.
That is, if slow phenomena = rare event.
-Mike
Irene Newhouse wrote:
> I'd like to save every picosecond, & for shorter runs I do. I'm
> interested in slower phenomena at this point, & I'm also at
> disadvantage due to a creaky internet connection. At the moment, I
> have to use the unix split command to split my tarballs into 500MB
> chunks & it's taking me as long to download the files for analysis as
> it was to run the MD in the first place. I'd love to be able to stride
> the files down BUT I'm using an older Desmond that's not compatible
> with the catdcd Desmond decoder AND it lacks manipulate_trj.py,
> the Desmond utility that accomplishes something similar. If you
> suggest I update the Desmond personally, I think it means you've not
> tried to install it. The support staff are working on an update, but
> it's not there yet. As soon as they crack that, I'll be in much better
> shape.
>
> Thanks for all the suggestions!
> Irene
>
> ------------------------------------------------------------------------
> Date: Tue, 22 Mar 2011 10:47:29 +0100
> From: bdrakuli_at_chem.bg.ac.rs
> To: rwoodphd_at_yahoo.com; namd-l_at_ks.uiuc.edu
> Subject: Re: namd-l: rule of thumb for dcd sampling frequency?
>
> Richard,
>
> Axel, as always, give best explanation
>
> Branko
>
>
> On 3/22/2011 12:43 AM, Richard Wood wrote:
>
> Wouldn't saving every picosecond be adequate?
>
> Richard
>
> ------------------------------------------------------------------------
> *From:* Branko <bdrakuli_at_chem.bg.ac.rs>
> <blockedmailto:bdrakuli_at_chem.bg.ac.rs>
> *To:* Irene Newhouse <einew_at_hotmail.com>
> <blockedmailto:einew_at_hotmail.com>; namd-l <namd-l_at_ks.uiuc.edu>
> <blockedmailto:namd-l_at_ks.uiuc.edu>
> *Sent:* Mon, March 21, 2011 2:13:51 PM
> *Subject:* Re: namd-l: rule of thumb for dcd sampling frequency?
>
> Irene,
>
> This strongly depend on what you planed to do with your output -
> i.e which type of analysis you want to do on your output. The best
> way to find most suitable sampling is to find how other sampled
> their systems looking on elements common to analysis of their
> systems and that which you planed At first 100 ns is very long, so
> maybe better to divide your simulation on phases - if you apply
> any biasing method carefully read NAMD ug before this. Second
> point is size of your system - contribute to the size of
> trajectory, especially if system is big and trajectory long. So
> according to my knowledge, the best way is to look on already
> published references and compare with your system and your need.
> God point to begin is:
> http://www.ks.uiuc.edu/Research/namd/papers.html#cites
> <blockedhttp://www.ks.uiuc.edu/Research/namd/papers.html#cites>,
> providing that you are already skilled in setting-up simulation
> and in analysis of output, in this respect the good way is to pass
> NAMD tutorials that can be found on the NAMD main web-page
> (http://www.ks.uiuc.edu/Research/namd/
> <blockedhttp://www.ks.uiuc.edu/Research/namd/>)
>
> Branko
>
> On 3/21/2011 7:26 PM, Irene Newhouse wrote:
>
> What are some rules of thumb for trajectory sampling? For
> instance, if you're intending to simulate for 100nsec, how
> many frames sample the time span adequately? 1 microsec?
> Pointers to references would be greatly appreciated.
>
> Thanks!
> Irene Newhouse
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com <blockedhttp://www.avg.com/>
> Version: 9.0.894 / Virus Database: 271.1.1/3519 - Release Date: 03/20/11 20:34:00
>
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com <blockedhttp://www.avg.com/>
> Version: 9.0.894 / Virus Database: 271.1.1/3520 - Release Date: 03/21/11 08:34:00
>
>
>
>
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:56:48 CST