From: Jim Phillips (jim_at_ks.uiuc.edu)
Date: Wed Dec 03 2003 - 15:38:04 CST
Hi,
This info line printed during startup will tell you what machine is
running the first NAMD process:
Info: Sending usage information to NAMD developers via UDP. Sent data is:
Info: 1 NAMD 2.5 Linux-i686 1 santiago.ks.uiuc.edu jim
You should connect to IMD on that node.
-Jim
On Mon, 1 Dec 2003, Brian Bennion wrote:
> Hello
>
> Has anyone had experience with VMD-IMD-NAMD on a massively parallel
> system?
> In my case I have NAMD working in an MPI environment on a couple of
> thousand processors. Each job is started with a native 'srun' command
> which is similar to the prun command noted in the docs.
>
> Which host would I tell the IMD interface to connect with?
>
> Thank you for your comments.
> Brian
>
>
> On Mon, 1 Dec 2003, Fangqiang Zhu wrote:
>
> > Hi,
> >
> > Please find comments from Justin Gullingsrud below. Hope it helps.
> >
> > Zhu
> >
> >
> >
> > From: "David E. Konerding" <dekonerding_at_lbl.gov>
> > Date: November 26, 2003 12:09:10 PM PST
> > To: namd-l_at_ks.uiuc.edu
> > Subject: namd-l: updating coordinates using IMD
> >
> >
> > Hi,
> >
> > I am interested in using IMD, I've gone through the code and managed
> > to write a simple Python extension (yes, I know about the python IMD
> > wrappers, but
> > I wanted a pure python version). It works OK in most cases, although
> > I find that the NAMD side is a bit flaky; sometimes it disconnects telling
> > me my
> > VMD version number is too old. When it does work I can collect forces
> > and energies.
> >
> >
> > What is probably happening is that you are not sending the GO message soon
> > enough after receiving the handshake message from NAMD. If NAMD doesn't
> > receive a
> > response within one second it drops the connection with an error message
> > about incompatible IMD versions. That message could admittedly be a bit
> > more helpful.
> >
> >
> > I have a few questions:
> >
> > 1) Is the IMD socket protocol truly asynchronous: the read and write
> > messages are totally distinct from each other (I'm more accustomed to
> > call/response style
> > protocols).
> >
> >
> > Yes, neither VMD nor NAMD wait for a response from each other. The idea is
> > that there is no point in resending coordinates or forces if something was
> > lost in transmission.
> > VMD is continually redrawing the screen based on the most recent
> > coordinates, and, when steering atoms with something like a haptic device,
> > forces are continually changing.
> > Making either system wait would decrease the responsiveness.
> >
> > 2) IMD doesn't seem to have any support for changing the coordinates
> > directly and getting an energy evaluation. IE, I want to NAMD to remain
> > paused, I
> > update all atomic coords to new ones, get back the energy given those
> > coords,
> > and NAMD goes back to a paused state.
> >
> >
> > Yes, there is currently support only for sending forces to a dynamics
> > simulation.
> >
> > My thinking was to add a new message, IMD_COORDS, which the client
> > could send to NAMD and update the coordinates. Then, another message,
> > IMD_GO_ONCE, would cause NAMD to evaluate forces/energies, send one
> > IMD_ENERGIES and one IMD_FCOORDS, and return to paused.
> >
> >
> > IMD_GO_ONCE shouldn't be any problem. For technical reasons I think it
> > would be difficult to make NAMD accept a new set of coordinate while the
> > simulation was running.
> > Jim Phillips could comment more precisely, but I think one would need to
> > suspend the simulation momentarily, apply the new coordinates, then resume,
> > and I'm not sure if the
> > current interface is capable of that.
> >
> > Cheers,
> > Justin
> >
> >
>
> --
> *****************************************************************
> **Brian Bennion, Ph.D. **
> **Computational and Systems Biology Division **
> **Biology and Biotechnology Research Program **
> **Lawrence Livermore National Laboratory **
> **P.O. Box 808, L-448 bennion1_at_llnl.gov **
> **7000 East Avenue phone: (925) 422-5722 **
> **Livermore, CA 94550 fax: (925) 424-6605 **
> *****************************************************************
>
>
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:37:12 CST