Project

General

Profile

Bug #108

Genion from Gromacs 3.3 and 3.3.1 does not produce output while consuming 100% CPU

Added by Mark Berjanskii about 13 years ago. Updated over 12 years ago.

Status:
Closed
Priority:
High
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

Hello,

Genion from Gromacs 3.3 and 3.3.1 compiled from the source on Linux computers
with Fedora Core 5/6 and Suse 10.1 does not produce an output while consuming
100% CPU. It looks like Gromacs can not be compiled properly with GCC 4.X.X.

See a description of the problem and found solution at
http://www.bionmr.com/board/showthread.php?p=198

You will likely be able to reproduce the problem if you try to install
Gromacs 3.3.1 on a Fedora Core 5 (or 6) or Suse 10.X computer and then add an
ion to the Gromacs cpeptide system generated by the Gromacs tutor/demo.

Cheers,

Mark Berjanskii
(happy user of Gromacs 3.2.1)

History

#1 Updated by David van der Spoel about 13 years ago

There was another complaint on the mailing list about g_dist. Apparently gcc
introduces a problem (or it shows gromacs problem not that are not found by
other compilers). Have you tried to use the rpms on the gromacs website?

I don't feel much like upgrading my compiler and not being able to compile
anymore :)

#2 Updated by Nicholas Breen almost 13 years ago

The glitch appears to be in pbc_dx() from gmxlib/pbc.c, though I didn't spot the
reason. I also found that it arose when using a cubic box, but not a dodecahedron.

This is what I got when ^C'ing a stuck genion run under gdb, compiled with GCC
4.1.2. (The run used '-nn 6', but after printing the first negative ion added
did not go any further.)

---------------------------------------------------------------------
Select a group: 12
Selected 12: 'SOL'
Number of (3-atomic) solvent molecules: 10667
Replacing solvent molecule 1251 (atom 3908) with Cl

Program received signal SIGINT, Interrupt.
0x080efac4 in pbc_dx (pbc=0xbfcb40e4, x1=0xb7cca738, x2=0xb7cbf74c,
dx=0xbfcb0d68) at pbc.c:237
237 while (dx[i] > pbc->hbox_diag[i]) {
(gdb) bt
#0 0x080efac4 in pbc_dx (pbc=0xbfcb40e4, x1=0xb7cca738, x2=0xb7cbf74c,
dx=0xbfcb0d68) at pbc.c:237
#1 0x08048d0f in insert_ion (nsa=3, nwater=<value optimized out>,
bSet=0x87c7ad8, repl=0x87f1c68, index=0x87a86d0,
pot=0x8788c40, x=0xb7cbf008, pbc=0xbfcb40e4, sign=-1, q=-1,
ionname=0x831c07d "Cl", mdatoms=0x8377e60,
rmin=0.600000024, bRandom=1, seed=0x8368f74) at gmx_genion.c:126
#2 0x0804a83d in gmx_genion (argc=1, argv=0xbfcb45f4) at gmx_genion.c:481
#3 0x0804820f in main (argc=1, argv=0x40dcbde4) at genion.c:50
(gdb) print i
$6 = 2
(gdb) print dx[i]
$7 = 7.67696626e-34
(gdb) print pbc->hbox_diag[i]
$8 = 3.44909


#3 Updated by David van der Spoel almost 13 years ago

Hi Nicholas,

could you please upload some example files?
It is most likely a compiler problem as the code at this point seems to be fine,
but maybe I can suggest a workaround if I can reproduce it.

#4 Updated by Dr. Marcelo almost 13 years ago

Dear All,

I have the same problem with "genion" running on GNU/Linux Ubuntu 6.10 and
Gromacs v. 3.3.1-1, so the final solution was simple. I just got the last
version of Gromacs to CentOS and converted it to .deb by "alien".
So the genion now works fine!

All the best!

#5 Updated by Mark Berjanskii almost 13 years ago

(In reply to comment #1)

There was another complaint on the mailing list about g_dist. Apparently gccto
introduces a problem (or it shows gromacs problem not that are not found by
other compilers). Have you tried to use the rpms on the gromacs website?

I tried and failed to install them. Gromacs 3.3 RPMs apparently can not be used
with default installations of Suse 10.X and Fedora Core 5 & 6 because of the
conflict with the mono-web package (see error message below). I do not want to
remove mono-web because too many other packages depend on it. Using CentOS is
also not the best option for me because it does not support hardware on my
computer as well as Suse and Fedora Core (and Ubuntu) do.
I guess I will try to figure out what .deb and "alien", that Dr. Lima mentioned,
mean and use them with Suse Linux to get a fully functional version of Gromacs
3.3.1 for my future Gromacs installations.

Thanks for your help!

Mark

Error message:

  1. rpm -Uvh gromacs-3.3-1.i386.rpm
    Preparing... ########################################### [100%]
    file /usr/bin/disco from install of gromacs-3.3-1 conflicts with file
    from package mono-web-1.1.18.1-12.2
    file /usr/share/man/man1/disco.1.gz from install of gromacs-3.3-1
    conflicts with file from package mono-web-1.1.18.1-12.2

#6 Updated by David van der Spoel over 12 years ago

Have you tried to rpm --ivh -force ?

#7 Updated by Nicholas Breen over 12 years ago

(In reply to comment #3)

Hi Nicholas,

could you please upload some example files?

I'm terribly sorry that I didn't notice this for months! I thought I was on the
bug cc: list, and so I was expecting to get e-mails if there was new activity...
my mistake.

An example file is available at: http://magnet.ofb.net/tmp/em.tpr
The command line I was testing was:
echo 12|genion -s em.tpr -o em_ion -g em_ion -nn 6 -pname Cl -pq 1

#8 Updated by David van der Spoel over 12 years ago

I was able to reproduce the bug using Debian x86 with gcc 4.1.2 (and also with
Fedora 6 x86 w/gcc 4.1.2, but not with Ubuntu x86_64 w/gcc 4.1.2).

A workaround is implemented in CVS (release-3-3-patches) now. This workaround is
mathematically equivalent, it consists of introducing a temporary variable to
store an intermediate result.

This is why I hate compilers...

Also available in: Atom PDF