From: 'Patrick Welche' (prlw1_at_cam.ac.uk)
Date: Mon Feb 08 2016 - 08:34:19 CST
On Mon, Feb 08, 2016 at 07:51:46AM +0100, Norman Geist wrote:
>
> What about NAMDs built-in velocity trajectory feature? Writing out a binary
> DCD trajectory istn't that much of a problem regarding disk space. Away from
> that, if you really want to hack the code, maybe the actual place where DCD
> trajectory files would be written might be a good place to start.
I was hoping to have shown that I have already tried all that in my first
message below:
- yes it is a problem regarding disk space
- the place where the files are written are called at the end of the time
step, where do I get to write to some memory which doesn't disappear /
get moved to maintain state for the next time step?
Cheers,
Patrick
> Norman Geist
>
> > -----Ursprüngliche Nachricht-----
> > Von: owner-namd-l_at_ks.uiuc.edu [mailto:owner-namd-l_at_ks.uiuc.edu] Im
> > Auftrag von Patrick Welche
> > Gesendet: Freitag, 5. Februar 2016 20:05
> > An: namd-l_at_ks.uiuc.edu
> > Betreff: namd-l: velocity computation
> >
> > Rather than write out a 6 TB pdb file containing velocities, just
> > to run a trivial little program over the data, I was wondering how
> > to simply keep something akin to a running sum of velocities. In a
> > non-parallel computing world, I could just grab an array, and at
> > each time step += elements in the array that would persist between
> > timesteps. What is the "correct" parallel way to do this? I see a
> > whole messaging framework. (The programmer's manual appeared to be
> > more about how the physics is implemented, and some of the classes
> > which seemed interesting from the messaging point of the view no
> > longer exist.)
> >
> > I suppose I am looking for "Hello World" where "Hello" comes from
> > the first timestep, and "World" the second...
> >
> > Cheers,
> >
> > Patrick
>
This archive was generated by hypermail 2.1.6 : Tue Dec 27 2016 - 23:21:48 CST