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

From: John Stone (johns_at_ks.uiuc.edu)
Date: Thu Apr 28 2005 - 10:08:17 CDT

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

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:40:42 CST