Re: velocity computation

From: Tristan Croll (tristan.croll_at_qut.edu.au)
Date: Tue Feb 09 2016 - 03:04:40 CST

Looks like a fairly simple tweak to Output.C to me. If I've read correctly, take lines 303 to 311:

    // Interactive MD
    if ( simParams->IMDon &&
       ( ((timestep % simParams->IMDfreq) == 0) ||
         (timestep == simParams->firstTimestep) ) )
    {
      IMDOutput *imd = Node::Object()->imd;
      wrap_coor(fcoor,lattice,&fcoor_wrapped);
      if (imd != NULL) imd->gather_coordinates(timestep, n, fcoor);
    }

remove the wrap_coor line, replace fcoor with vel and move the whole lot into the velocity proc (starting from line 392). Or have I missed something? You'd obviously lose the ability to do normal IMD, but for a special purpose build of NAMD that isn't so important.

________________________________________
From: Norman Geist <norman.geist_at_uni-greifswald.de>
Sent: Tuesday, 9 February 2016 6:22 PM
To: Tristan Croll
Cc: namd-l_at_ks.uiuc.edu
Subject: AW: namd-l: velocity computation

I don't want to hinder anybody's enthusiasm but buying another HDD and save
vel.dcd files is maybe the less time consuming solution and therefore the
cheaper one usually. The NAMD source is hard to modify by people that don't
know the structure behind it.

Away from that, even for large systems, with high frequent frame writes, a
DCD file won't grow larger that some 100th of GB, not 6TB as it would maybe
be when using ascii PDB files.

But I like Tristans idea of using the IMD interface.

Best wishes
Norman Geist

> -----Ursprüngliche Nachricht-----
> Von: Tristan Croll [mailto:tristan.croll_at_qut.edu.au]
> Gesendet: Montag, 8. Februar 2016 19:33
> An: Norman Geist <norman.geist_at_uni-greifswald.de>; namd-l_at_ks.uiuc.edu;
> 'Patrick Welche' <prlw1_at_cam.ac.uk>
> Betreff: Re: namd-l: velocity computation
>
> Just a thought, but you could probably hack the IMD connection to VMD
quite
> straightforwardly to achieve this. Edit the NAMD source code to send the
> velocities rather than the coordinates, then in VMD:
>
> trace add variable ::vmd_timestep(your_imd_molecule_number) write
> your_proc
>
> ... and a proc to do whatever you want to do with the velocity
information. As
> long as you're not asking VMD to actually draw anything, the
back-and-forth
> should be fairly minimal.
>
> ________________________________________
> From: owner-namd-l_at_ks.uiuc.edu <owner-namd-l_at_ks.uiuc.edu> on behalf of
> 'Patrick Welche' <prlw1_at_cam.ac.uk>
> Sent: Tuesday, 9 February 2016 12:34 AM
> To: Norman Geist
> Cc: namd-l_at_ks.uiuc.edu
> Subject: Re: namd-l: velocity computation
>
> 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 : Sun Dec 31 2017 - 23:20:10 CST