This is caused because _short_ene.f is rewritten during the compilation of
sander.LES(.MPI), so this file is not actually the preprocessed file for the
executable you're running. What you should do is go to the sander source
directory and type "make sander(.MPI)", so that it doesn't build the LES
version. Then you should see line numbers add up.
Hope this helps,
Jason
On Thu, Mar 31, 2011 at 11:56 AM, Albert Lee <hojoon.lee.yahoo.com> wrote:
> The line numbers are from _short_ene.f.
>
> --- On Thu, 3/31/11, Adrian Roitberg <roitberg.qtp.ufl.edu> wrote:
>
> From: Adrian Roitberg <roitberg.qtp.ufl.edu>
> Subject: Re: [AMBER] Inconsistencies between reported lines and executed
> lines in source code
> To: "AMBER Mailing List" <amber.ambermd.org>
> Date: Thursday, March 31, 2011, 1:33 PM
>
> Are you looking at line numbers in the _short_ene.f or in the
> short_ene.f files ?
> There is a difference in numbering due to the initial cpp preprocessing
> and the IFDEFS that get interpreted and deleted when the final,
> compilable code is used.
>
> Adrian
>
>
> On 3/31/11 2:12 PM, Albert Lee wrote:
> > Hi, everyone.
> >
> > I'm a research assistant using a modified form of AMBER 10, and I'm
> trying to perform some optimization on this modified form. Naturally, I've
> been working with a debugger for this purpose (GDB, mostly), and I've come
> across some strange behavior in _short_ene.f. Once the program hits the
> short_ene_ subroutine, it jumps about 300 lines and ends up in the wrong
> place. That is, GDB will report stepping from the start of the subroutine,
> at line 521, to line 862, when in reality, the program is actually executing
> line 951. In other words, there is an offset between the reported line by
> GDB and the executed line by sander.
> >
> > I've noticed this happening in other areas, but it is most striking in
> short_ene_, as far as I can tell. Line deviations range from about 500 lines
> to 450 lines in the eedmeth "if" block. My question, then, is: why does this
> behavior occur?
> >
> > The modified form of AMBER isn't the issue, as after I noticed this, the
> first thing I did was to check the basic AMBER 10 install, which produces
> the same results. All of the compilations of AMBER I've done have been with
> -g and -O0 options when applicable; I've compiled with gfortran and g95, and
> tried out dbx, to no avail.
> >
> > I'm running AMBER 10 on CentOS Linux, i386, as a virtual machine on
> Oracle VirtualBox.
> >
> >
> >
> >
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
> >
>
> --
> Dr. Adrian E. Roitberg
> Associate Professor
> Quantum Theory Project, Department of Chemistry
> University of Florida
>
> on Sabbatical in Barcelona until August 2011.
> Email roitberg.ufl.edu
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Mar 31 2011 - 12:30:04 PDT
