Re: Re: vmd-l: Interactive Simulations, ligand size limits....

From: Brian Bennion (brian_at_youkai.llnl.gov)
Date: Thu Apr 28 2005 - 12:01:32 CDT

Hi John and others

We to have seen problems with forces communicated by IMD communication
pathway. Energy is not conserved even for timessteps as low as 1 a.u.

namd running the same system without input from imd conserves energy just
fine. But as soon as data from IMD comes in things go bad.

Our current test system is 2 atoms....

I to would be interested in helping solve this problem....

Brian

On Thu, 28 Apr 2005, John Stone wrote:

>
> Luis,
> That's good information, exactly what I wanted to know.
> I agree that this must be some sort of bug (or maybe a missing safety
> check) in the NAMD end of the communcation channel. We'll have
> to debug the code in NAMD that handles this and see if it's indeed
> a bad memory buffer, or simply some disagreement between what VMD is
> sending and what NAMD is expecting to receive. Could be either one.
> In the mean time, if you want to pull on a particular fragment,
> I'd suggest that you try doing it with the "assigned rep" feature
> in the Graphics->Tools->Assigned Rep tab. That should allow you
> to select the fragment of interest and apply force on it, though
> done in a little different way. If that also gives you a crash,
> then we're onto something interesting, if not, then you should be
> able to use that for the short-term. (I'm assuming here that you're
> using a 3-D tracker or haptic device, and not just using the Mouse right?)
>
> John Stone
> vmd_at_ks.uiuc.edu
>
> On Wed, Apr 27, 2005 at 09:29:51PM -0500, Luis Rosales wrote:
> >
> > Hi all!
> > John,
> >
> > I just finished the tests that John suggested, namely, I ran a couple of IMD
> > simulations using a couple of linux servers. I used the same input files as in
> > the remote simulations on the alpha server.
> > I got the same behaviour on NAMD: For my system with 1 protein and 1 protein
> > fragment, the simulation is killed if I apply a force on the fragment if the
> > latter is bigger than 15 residues. Tests with smaller fragment sizes run fine,
> > unless I apply an excesive force on the fragment (but that is expected...).
> >
> > This time I used as the local machine the same RedHat Linux server to run VMD
> > and I ran the simulations on a debian linux server with NAMD 2.5.
> > The error messages are attached at the end of the mail...
> >
> > So, maybe the error is not related to a floating point exception...
> > Could be related to limitations on the memory buffer that NAMD uses to
> > communicate with VMD???
> >
> > Again, thanks for your help,
> >
> > Luis
> >
> >
> > ***********************************************************
> > I ran this test on a system with 2 proteins and 0 waters, for a total
> > of 110 residues (1651 atoms). One protein is 85 residues long and the 2nd is
> > 20 residues long.
> > ***********************************************************
> >
> > Info: Pausing IMD
> > Info: Resuming IMD
> > Info: Pausing IMD
> > Info: Resuming IMD
> > DEBUG: Detaching simulation from remote connection
> > ------------- Processor 0 Exiting: Caught Signal ------------
> > Signal: segmentation violation
> > Suggestion: Try running with '++debug', or linking with '-memory paranoid'.
> > Stack Traceback:
> > [0] _ZN15GlobalMasterIMD9calculateEv+0x2ef [0x81c5b3f]
> > [1]
> > _ZN12GlobalMaster11processDataEPiS0_P6VectorS2_S2_S0_S0_S2_S0_S0_S2_+0x6f
> > [0x81c16df]
> > [2] _ZN18GlobalMasterServer11callClientsEv+0x428 [0x81c3384]
> > [3] _ZN18GlobalMasterServer8recvDataEP20ComputeGlobalDataMsg+0x44a [0x81c2b22]
> > [4] _ZN10ComputeMgr21recvComputeGlobalDataEP20ComputeGlobalDataMsg+0x1c
> > [0x811b034]
> > [5]
> > _ZN18CkIndex_ComputeMgr48_call_recvComputeGlobalData_ComputeGlobalDataMsgEPvP10ComputeMgr+0x11
> > [0x811b011]
> > [6] CkDeliverMessageFree+0x21 [0x827c1f9]
> > [7] _Z15_processHandlerPvP11CkCoreState+0x393 [0x827d5e3]
> > [8] CmiHandleMessage+0x1d [0x82b5e25]
> > [9] _ZN9ScriptTcl7suspendEv+0xc [0x8228c68]
> > [10] _ZN9ScriptTcl13runControllerEi+0x3f [0x8228c4f]
> > [11] _ZN9ScriptTcl7Tcl_runEPvP10Tcl_InterpiPPc+0xf4 [0x82292cc]
> > [12] TclInvokeStringCommand+0x6d [0x82c5145]
> > [13] /usr/local/NAMD_2.5_Linux-i686/namd2 [0x82f946a]
> > [14] Tcl_EvalEx+0x1cc [0x82f9b7c]
> > [15] Tcl_EvalFile+0x157 [0x82f1ce3]
> > [16] _ZN9ScriptTcl3runEPc+0x1a [0x8228b76]
> > [17] main+0x1d2 [0x80ed052]
> > [18] __libc_start_main+0xf4 [0xb7e87974]
> > [19] sinh+0x65 [0x80eaed1]
> > req_handle_abort called
> > Fatal error on PE 0> segmentation violation
> >
> >
> > ---------- Original Message -----------
> > > Luis,
> > > It sounds to me like NAMD is encountering a floating point
> > > exception during your run. Alpha processors don't handle such
> > > exceptions gracefully unless you compile code specially (i.e. slower
> > > performance), it's possible that the version of NAMD you're running
> > > has some math that's problematic, or it's operating on FP values
> > > sent to it by VMD that give the Alpha CPUs problems. What happens
> > > if you run the NAMD side of things on a Linux box? It should be
> > > relatively easy to fix the problem if we can reproduce it on a
> > > machine we can run NAMD on. These FP exceptions are a familiar
> > > issue on the Alpha platform.
> > >
> > > John Stone
> > > vmd_at_ks.uiuc.edu
> > >
> > > --
> > > NIH Resource for Macromolecular Modeling and Bioinformatics
> > > Beckman Institute for Advanced Science and Technology
> > > University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> > > Email: johns_at_ks.uiuc.edu Phone: 217-244-3349
> > > WWW: http://www.ks.uiuc.edu/~johns/ Fax: 217-244-6078
> >
> >
> > From: John Stone <johns_at_ks.uiuc.edu>
> > To: Luis Rosales <ludwig_at_correo.biomedicas.unam.mx>
> > Cc: namd-l_at_ks.uiuc.edu, vmd-l_at_ks.uiuc.edu
> > Sent: Wed, 20 Apr 2005 16:12:20 -0500
> > Subject: namd-l: Re: vmd-l: Interactive Simulations, ligand size limits....
> >
> > > Luis,
> > > How large is the molecule you're simulating? When you say that
> > > the simulation "crashed", does that mean that NAMD aborted because
> > > you pulled too hard (margin violation, exceeding the speed of light,
> > > etc...), or did NAMD actually have a seg fault or floating point exception
> > > of some kind? If you got a "margin violation" it means that you pulled
> > > on the structure so hard that you exceeded NAMD's internal limit on
> > > atom velocity imposed by the spatial decomposition it uses. If you
> > > pull to hard and impart a tremendous velocity per simulated timestep,
> > > this means that either you need to pull more gently, or you need to
> > > decrease the gap in timescale between your real-time pulling and the
> > > rate of simulated time in the simulation, either by using a smaller
> > > molecule or by using fixed atoms, or some combination of both.
> > >
> > > John Stone
> > > vmd_at_ks.uiuc.edu
> > >
> > > --
> > > NIH Resource for Macromolecular Modeling and Bioinformatics
> > > Beckman Institute for Advanced Science and Technology
> > > University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> > > Email: johns_at_ks.uiuc.edu Phone: 217-244-3349
> > > WWW: http://www.ks.uiuc.edu/~johns/ Fax: 217-244-6078
> > ------- End of Original Message -------
>
> --
> NIH Resource for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> Email: johns_at_ks.uiuc.edu Phone: 217-244-3349
> WWW: http://www.ks.uiuc.edu/~johns/ Fax: 217-244-6078
>

************************************************
  Brian Bennion, Ph.D.
  Bioscience Directorate
  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:39:23 CST