[lammps-users] compiling lammps with gcc -g

Hi,

this is a quite special question regarding running lammps under SUSE linux and using the compiler switch -g.

We are using some self-made fixes, which work without problems under Windows, using VC++.
It was also running in principle at the SUSE system, compiling with gcc by using the attached makefile. But we had several crashes due to memory corruption and MPI also reported crashes due to corrupted pointers. This occured mainly when running parallel.
After trying to locate the errors, we just took out the compiler option -g (which should be for debugging information). Without -g everything seems to run without crashing

Also, the code was not stable for a simulation with Au/Cu EAM potential when using a timestep of 0.0027ps, when using the -g option. Without -g it workes.

Now, I am a bit puzzled, because running in debug or optimised mode should not make a difference to the results of the simulation
(ok, beside random numerical errors due to finite digits).
Does anybody has experience with this problem or knows the reason for the strange behaviour. This would certainly help to increase my trust in the simulation results :-).

Many thanks,
Marco

Makefile.g++ (821 Bytes)

Hi Marco. Do you see these problems when compiling and
running without your self-made fixes? Perhaps you
could try your experiment again, but this time with
the latest standard LAMMPS distribution. That would
help determine if the problem is with the code you've
added or with the standard package. -Paul

Hi,

this is a quite special question regarding running
lammps under SUSE
linux and using the compiler switch -g.

We are using some self-made fixes, which work
without problems under
Windows, using VC++.
It was also running in principle at the SUSE system,
compiling with gcc
by using the attached makefile. But we had several
crashes due to memory
corruption and MPI also reported crashes due to
corrupted pointers. This
occured mainly when running parallel.
After trying to locate the errors, we just took out
the compiler option
-g (which should be for debugging information).
Without -g everything
seems to run without crashing

Also, the code was not stable for a simulation with
Au/Cu EAM potential
when using a timestep of 0.0027ps, when using the -g
option. Without -g
it workes.

Now, I am a bit puzzled, because running in debug or
optimised mode
should not make a difference to the results of the
simulation
(ok, beside random numerical errors due to finite
digits).
Does anybody has experience with this problem or
knows the reason for
the strange behaviour. This would certainly help to
increase my trust in
the simulation results :-).

Many thanks,
Marco
> # g++ = RedHat Linux box, g++, MPICH, FFTW

SHELL = /bin/sh
#.IGNORE:

# System-specific settings

CC = g++
CCFLAGS = -g -O -I/home/sjplimp/tools/mpich/include
\
    -I/home/sjplimp/tools/fftw/include
-I/home/sjplimp/lammps/poems \
    -DFFT_FFTW -DGZIP
DEPFLAGS = -M
LINK = g++
LINKFLAGS = -g -O -L/home/sjplimp/tools/mpich/lib \
    -L/home/sjplimp/tools/fftw/lib
-L/home/sjplimp/lammps/poems
USRLIB = -lfftw -lmpich -lpoems
SYSLIB =
ARCHIVE = ar
ARFLAGS = -rc
SIZE = size

# Link target

\(EXE\): (OBJ)
  \(LINK\) (LINKFLAGS) \(OBJ\) (USRLIB) \(SYSLIB\) \-o (EXE)
  \(SIZE\) (EXE)

# Library target

lib: \(OBJ\)   (ARCHIVE) \(ARFLAGS\) (EXE) $(OBJ)

# Compilation rules

\.o:.cpp
  \(CC\) (CCFLAGS) -c $<

\.d:.cpp
  \(CC\) (CCFLAGS) \(DEPFLAGS\) < > [email protected]

# Individual dependencies

DEPENDS = \(OBJ:\.o=\.d\) include (DEPENDS)
> Using Tomcat but need to do more? Need to support
web services, security?
Get stuff done quickly with pre-integrated
technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1
based on Apache Geronimo

http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

> _______________________________________________
lammps-users mailing list
[email protected]

https://lists.sourceforge.net/lists/listinfo/lammps-users

Hi Paul,

thanks for your answer. It only happens, when we use our fix "setvelbyforce", but this fix is quite simple and debugging with printf(..) commands shows that the error does occur within the code of the fix. Ok, by overwriting memory bounds, we could influence other parts of the code and cause them to behave strange, but I have run a bounds checker tool for VC++ and it did not complain about any memory violation.
Just in case, I have added the script and the fix source code.

Another member of our group suggested that this could also be caused by MPICH, but I do not know if and how buggy it is.

We will run it again by using the latest version of Lammps and see how it behaves.

cheers,
Marco

Paul Crozier wrote:

fix_setvelbyforce.cpp (5.94 KB)

fix_setvelbyforce.h (1.59 KB)

EquilbrCu-Ag.in (1.09 KB)