Re: NAMD crashed with TclForce turned on

From: Vlad Cojocaru (Vlad.Cojocaru_at_eml-r.villa-bosch.de)
Date: Wed Aug 13 2008 - 07:31:03 CDT

Dear Axel, Dear all,

Just to let you know that I do not manage to run tclforces scripts in an
namd compiled with tcl8.5.3. In your last email you mentioned that it
worked for you. I still get segmentation faults independent of the
compiler (I tried both gcc 4.1.2 and icc 10.1.015), compiler flags and
so on ...

Best wishes
vlad

Axel Kohlmeyer wrote:
> On Sun, 10 Aug 2008, Cojocaru,Vlad wrote:
>
> VC>
> VC> Thanks Axel !!
> VC>
> VC> Its good to know ... Which compiler did you use and what level of optimization?
>
> gcc 4.1 (default on fedora 6)
>
> VC> I have to say I tried only the intel 10.1 since it was the default
> VC> compiler on our system ... But then I noticed that for tcl, gcc
>
> you mean that "cc" was pointing to "icc"?
>
> have you checked the patch level on your intel compiler?
> early patchlevels (particularly 008) have a lot of problems.
>
> VC> works much cleaner. From intel I got lots of warnings during
> VC> compilation which I did not get when compiling with gcc ... But I
> VC> haven't tried tcl8.5 with gcc ....
>
> this is because the default settings for icc are similar to running
> gcc with -std=c89 -Wall -W . what is a meaningful warning has to
> be decided on a case by case basis. when building libraries for
> system-wide use, it is good to be conservative and careful. so
> gcc -O2 is generally a good compromise. the execution speed of
> the tcl lib should have _very_ little impact on the speed up namd.
>
> whether gcc is cleaner or icc is a matter of debate.
> gcc is very forgiving to some common, but not 100%
> correct constructs. OTOH, gcc assumes ANSI-c aliasing compliance
> by default (which allows additional optimizations) and icc
> doesn't. so some codes that do some unusual pointer magic
> need to be compiled with -fno-ansi-aliasing added (at least in part).
>
> VC>
> VC> What do you mean "to undefine the -DUSE_NON_CONST flag" ? Is it used
> VC> by default during the compilation of tcl8.5 ?
>
> the namd cvs code defines USE_COMPAT_CONST in the headers that
> include tcl.h. defining USE_NON_CONST is incompatible with that
> (see tcl.h). that same should be true for tcl8.4 if you compile
> the cvs. hence my suspicion that you compiled against an
> inconsistent version of the tcl header. this can easily cause
> segfaults regardless of the compiler.
>
> FWIW, i just tried with icc (10.1.015) and it works fine with
> tcl forces as well. either only using an icc compiled tcl or
> namd (latest cvs) and tcl compiled with icc.
>
> cheers,
> axel.
>
>
> VC>
> VC> Best wishes
> VC> vlad
> VC>
> VC>
> VC>
> VC>
> VC> -----Original Message-----
> VC> From: akohlmey_at_gmail.com on behalf of Axel Kohlmeyer
> VC> Sent: Sun 8/10/2008 12:14 AM
> VC> To: Cojocaru,Vlad
> VC> Cc: Chi-Cheng Chiu; namd-l_at_ks.uiuc.edu
> VC> Subject: Re: namd-l: NAMD crashed with TclForce turned on
> VC>
> VC> On Thu, Aug 7, 2008 at 3:48 PM, Cojocaru,Vlad
> VC> <vlad.cojocaru_at_eml-r.villa-bosch.de> wrote:
> VC> >
> VC> > Sorry,
> VC> >
> VC> > in fact it does compile with tcl8.5 but it crashes with tclforces scripts
> VC>
> VC> ...and it works, too. i just compiled the current NAMD cvs code together
> VC> with tcl8.5.3 on my desktop and i can run, e.g., the tcl-forces tutorial inputs
> VC> without a problem.
> VC>
> VC> -DUSE_NON_CONST is no longer required (in fact you have to undefine it
> VC> to be able to compile).
> VC>
> VC> in conclusion the crashes are most likely due to miscompiled code due
> VC> to overoptimization
> VC> and/or compiler bugs or inconsistent use of header files (an
> VC> older/installed header file was used
> VC> instead of the one matching the library.
> VC>
> VC> thought you might want to know...
> VC>
> VC> cheers,
> VC> axel.
> VC>
> VC> > ...
> VC> >
> VC> > Mea culpa
> VC> >
> VC> > vlad
> VC> >
> VC> > -----Original Message-----
> VC> > From: Cojocaru,Vlad
> VC> > Sent: Thu 8/7/2008 9:43 PM
> VC> > To: Chi-Cheng Chiu; Axel Kohlmeyer
> VC> > Cc: namd-l_at_ks.uiuc.edu
> VC> > Subject: RE: namd-l: NAMD crashed with TclForce turned on
> VC> >
> VC> > Yes,
> VC> >
> VC> > Namd does not compile with tcl8.5. As I wrote in the last email of that
> VC> > discussion, you should either use the precompiled libraries provided on the
> VC> > namd page or compile yourself tcl 8.4.19 with the -DUSE_NON_CONST defined in
> VC> > the CFLAGS. tcl8.3.x does not configure in a newer version of bash ..
> VC> >
> VC> > Hope this helps
> VC> > vlad
> VC> >
> VC> >
> VC> > -----Original Message-----
> VC> > From: Chi-Cheng Chiu [mailto:ccchiu_at_student.utdallas.edu]
> VC> > Sent: Thu 8/7/2008 6:17 PM
> VC> > To: Axel Kohlmeyer; Cojocaru,Vlad
> VC> > Cc: namd-l_at_ks.uiuc.edu
> VC> > Subject: Re: namd-l: NAMD crashed with TclForce turned on
> VC> >
> VC> > Thanks for the idea!
> VC> > We compiled NAMD linking to Tcl8.5 by setting up the
> VC> > "arch/Linux-amd64.tcl" file:
> VC> > TCLINCL=-I/usr/include
> VC> > TCLLIB=-L/usr/lib64 -ltcl8.5 -ldl
> VC> > TCLFLAGS=-DNAMD_TCL -DUSE_NON_CONST
> VC> > TCL=$(TCLINCL) $(TCLFLAGS)
> VC> >
> VC> > We also tried setup env
> VC> > LD_LIBRARY_PATH=/usr/lib64
> VC> >
> VC> > but we still get "signal 11" error when running NAMD through mpirun
> VC> > with tclforce turn on.
> VC> > In NAMD archive, there's an article saying that NAMD hasn't been tested
> VC> > with Tcl8.5. Could the problem be the compatibility of Tcl 8.5 wiht
> VC> > NAMD?
> VC> >
> VC> > Thanks in advance
> VC> >
> VC> > Cheers,
> VC> >
> VC> > Chi-cheng
> VC> >
> VC> > Axel Kohlmeyer wrote:
> VC> >
> VC> >
> VC> >>On Wed, 6 Aug 2008, Chi-Cheng Chiu wrote:
> VC> >>
> VC> >>CCC> Hi All,
> VC> >>CCC> We compile charm++(version 6.0) and namd on a cluster with AMD
> VC> > Opteron
> VC> >>CCC> 280 and Myrinet MX connection using MPI and PGI compiler. We can
> VC> > launch
> VC> >>
> VC> >>why PGI? g++/gcc is usually significantly faster _and_ much more
> VC> > reliable.
> VC> >>
> VC> >>CCC> NAMD with mpirun normally. Yet if we turn on TclForce, NAMD
> VC> > crashed
> VC> >>CCC> with the following error info while loading the atom's coordinate:
> VC> >>CCC>
> VC> >>CCC> /net/ss/cm/u1/son051000/N/Linux-amd64-MPI/namd2:signal 11
> VC> >>CCC> MX:s47.utdallas.edu:Remote endpoint is closed,
> VC> > peer=00:60:dd:47:ec:a9
> VC> >>CCC> (s75.utdal
> VC> >>CCC> las.edu:0)
> VC> >>
> VC> >>CCC> We are not sure which part of NAMD went wrong. Does anyone have an
> VC> > idea
> VC> >>CCC> about this?
> VC> >>
> VC> >>most likely the tcl interpreter? without seeing what was leading up
> VC> >>to the segfault (=signal 11) it is difficult to tell.
> VC> >>
> VC> >>please also see the discussion on the very same subject of compiling
> VC> >>and running with tcl from the last few days in the list archives.
> VC> >>
> VC> >>cheers,
> VC> >> axel.
> VC> >>
> VC> >>CCC>
> VC> >>CCC> Thanks
> VC> >>CCC>
> VC> >>CCC> Chi-cheng
> VC> >>CCC>
> VC> >>
> VC> >>--
> VC> >>=======================================================================
> VC> >>Axel Kohlmeyer akohlmey_at_cmm.chem.upenn.edu http://www.cmm.upenn.edu
> VC> >> Center for Molecular Modeling -- University of Pennsylvania
> VC> >>Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
> VC> >>tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425
> VC> >>=======================================================================
> VC> >>If you make something idiot-proof, the universe creates a better idiot.
> VC> >>
> VC> >
> VC> >
> VC> >
> VC>
> VC>
> VC>
> VC>
>
>

-- 
----------------------------------------------------------------------------
Dr. Vlad Cojocaru
EML Research gGmbH
Schloss-Wolfsbrunnenweg 33
69118 Heidelberg
Tel: ++49-6221-533266
Fax: ++49-6221-533298
e-mail:Vlad.Cojocaru[at]eml-r.villa-bosch.de
http://projects.villa-bosch.de/mcm/people/cojocaru/
----------------------------------------------------------------------------
EML Research gGmbH
Amtgericht Mannheim / HRB 337446
Managing Partner: Dr. h.c. Klaus Tschira
Scientific and Managing Director: Prof. Dr.-Ing. Andreas Reuter
http://www.eml-r.org
----------------------------------------------------------------------------

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:48:10 CST