[gmx-users] 3.1 problems still on SP

[David L. Bostick]

Hi Erik,

I continue to have problems running the mpi enabled version of mdrun
on gmx3.1 on the SP.  I get all the environmental variables set so that it
compiles succesfully without complaints, but it consistently gives
segmentation faults no matter what system or set of simulation controls I
throw at it.

I thought it might have something to do with grompp3.1 or the way my
simulation was controlled in the input .mdp file for grompp3.1.  So, to put
this idea to rest I built a test system .tpr file using grompp2.0 that has
been working on my SP for a long time.  I then ran the test run with this
.tpr file from gmx2.0 as input for mdrun2.0, a compiled version of
mdrun3.0, and a compiled version of mdrun3.1.  The only program that
doesn't seem to work is mdrun3.1.  The segmentation fault cannot be due to 
the difference in tpx file_version because I get similar errors for 3.1 no 
matter which grompp I use.

I get the following:

for mdrun2.0 Standard out gives:

starting mdrun 'huge bilayer with 576 dppc molecules'
500 steps,      1.0 ps.

for mdrun3.0 Standard out gives:

Reading file 64.tpr, VERSION 2.0 (single precision)
Reading file 64.tpr, VERSION 2.0 (single precision)
Note: tpx file_version 11, software version 20

starting mdrun 'huge bilayer with 576 dppc molecules'
500 steps,      1.0 ps.

for mdrun3.1 Standard out gives:

Reading file 64.tpr, VERSION 2.0 (single precision)
Reading file 64.tpr, VERSION 2.0 (single precision)
Note: tpx file_version 11, software version 24

starting mdrun 'huge bilayer with 576 dppc molecules'
500 steps,      1.0 ps.
 
ERROR: 0031-250  task 0: Segmentation fault
ERROR: 0031-250  task 3: Terminated
ERROR: 0031-250  task 2: Terminated
ERROR: 0031-250  task 4: Terminated
ERROR: 0031-250  task 1: Terminated
ERROR: 0031-250  task 5: Terminated
ERROR: 0031-250  task 9: Terminated
ERROR: 0031-250  task 6: Terminated
ERROR: 0031-250  task 8: Terminated
ERROR: 0031-250  task 7: Terminated

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
David Bostick					Office: 262 Venable Hall
Dept. of Physics and Astronomy			Phone:  (919)962-0165 
Program in Molecular and Cellular Biophysics 
UNC-Chapel Hill					
CB #3255 Phillips Hall				dbostick at physics.unc.edu	
Chapel Hill, NC 27599	           		http://www.unc.edu/~dbostick	
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

On Sat, 6 Apr 2002, Erik Lindahl wrote:

> Hi,
> 
> > Marc Baaden's warning about the somewhat unexpected behavior of grompp when
> > having multiple atomtypes and non-bonded entries applies to using lipid.itp
> > too. In the way I set it up, the LJ interaction matrix in the GROMOS based
> > force fields (ffgmx in this case) is overwritten with standard combination
> > rules. I don't yet know what the effect is of this. It means the force field
> > isn't used the way it was designed. On the other hand, nearly all published
> > simulations on membrane proteins with gromacs will have used the combination
> > rules for the protein part instead of the GROMOS values, often without
> > disastrous consequences.
> > 
> > To use the protein-protein GROMOS LJ parameters, the contents of lipid.itp
> > should be copied into the ffgmx* files as Marc described. It should be
> > possible to test the differences on simulations of high-resolution membrane
> > protein structures.
> 
> This is definitely a bug that should definitely fix; the immediate 
> solution is to give a warning if there's more than one atom or 
> nonbonded-parameter section, and then we'll have think of the proper way 
> to treat topologies with more than one section...
> 
> Almost everything in GROMOS96 is based on combination rules though; the 
> only exception is some of the C12 paratermer where another atom 
> interacts with water oxygen atoms, and the difference isn't large.
> 
> Cheers,
> 
> Erik
> 
> _______________________________________________
> gmx-users mailing list
> gmx-users at gromacs.org
> http://www.gromacs.org/mailman/listinfo/gmx-users
> Please don't post (un)subscribe requests to the list. Use the 
> www interface or send it to gmx-users-request at gromacs.org.
>