From: Gengbin Zheng (gzheng_at_ks.uiuc.edu)
Date: Thu Dec 30 2004 - 15:23:30 CST
Hi John,
Welcome to the real Unix world! Imagining how many different
architectures/venders/operating systems/communication hardwares and
libraries/compilers you need to deal with in UNIX and its parallel
flavors that NAMD faces (compared with windows applications).
While we are trying to support as many environments as possible
including windows, each porting requires additional effort and require
followups due to vender libraries upgrades (clustermaric 3 and 4 for
example is not backward compatiable due to change in bproc). Making
binaries for all these environments is simply impossible and can be
error prone when people trying to install redhat7 binaries on a redhat 9
box for example. And we are simply lack of man power for doing such
customer support and we don't have access to all machines with that many
different configurations for doing compilations! ;-)
Compiling Charm++/NAMD is difficult inherited from the complexity of
parallel architectures, but it is the best because you can customize
build for your needs according to the machine configuration. So far,
NAMD runs on machines from PC Linux/windows, IA64, Opteron, Dec Alpha
(our favorite for writing paper :) to IBM Bluegene/L whiling supporting
100M/Gigabit ethernet, myrinet, quadrics and infiniband. Most of times,
compilation problems are due to compiler issues (sometimes even compiler
bug) and vender library upgrades/compatibility problems.
There are a lot of resource contributed by users also about how to
compile NAMD such as NAMD wiki, and there are many successful stories
installing NAMD presented in namd mailist which you can explore in the
archive. Btw, we dont expect major problem of compiling NAMD on
clustermatic 4 and opteron, you can always try to download latest
Charm/NAMD from our cvs server since problem may have been solved after
the previous release. Don't know clustermatic 5 yet since I don't know
if they have major change in bproc library this time. And people are
welcome to send bug report to NAMD developer group (namd_at_ks.uiuc.edu)
or to this mailing list, as well as their complaints. Compiling
Charm++/NAMD is difficult, but if you are really determined to do it and
spend a little time exploring or asking around for help, you will make
it. In worst cases, it happened that people are willing to give me
account to their machines, in which case I will just go ahead and spend
half hour compling Charm++/NAMD for them.
I am not sure about the release plan in the near future (since in
university, our main interest is in writing paper and/or thesis :-) ).
However we are currently in the design/implementation phase of next
generation of NAMD3. At the same time, NAMD2 is still actively
maintained and getting improved along with Charm++.
Gengbin
John Saeger wrote:
> Gosh, I'm surprise you're having a problem. (just kidding) To tell
> you the truth, I've never been able to compile NAMD either. This
> wouldn't bother me so much if NAMD binaries were kept up to date.
> There have been no new binaries released since September 2003. So we
> don't have Clustermatic 4 and we don't have Clustermatic 5. We don't
> have Opterons either. But if we have a warehouse full of Dec Alphas
> or something like that we're in fine shape.
>
> I know this wasn't very helpful, but I just wanted to let you know
> that you are not alone, and if you figure it out, you should tell us
> how you got NAMD to compile.
>
> John
>
>
>
> Ruxandra Dima wrote:
>
>> Hello,
>>
>> I have problems using the Namd-2.5 precompiled binaries on a Fedora
>> Core 3
>> workstation. My runs terminate randomly with the error
>>
>> Stack Traceback:
>> [0] _ZN16ComputePatchPair6doWorkEv+0xa4 [0x8192b34]
>> [1] _ZN11WorkDistrib12enqueueWorkBEP12LocalWorkMsg+0x19 [0x824b9cd]
>> [2]
>> _ZN19CkIndex_WorkDistrib31_call_enqueueWorkB_LocalWorkMsgEPvP11WorkDistrib+0x11
>>
>> [0x824b9ad]
>> [3] CkDeliverMessageFree+0x21 [0x827c1f9]
>> [4] _Z15_processHandlerPvP11CkCoreState+0x393 [0x827d5e3]
>> [5] CmiHandleMessage+0x1d [0x82b5e25]
>> [6] _ZN9ScriptTcl7suspendEv+0xc [0x8228c68]
>> [7] _ZN9ScriptTcl13runControllerEi+0x3f [0x8228c4f]
>> [8] _ZN9ScriptTcl7Tcl_runEPvP10Tcl_InterpiPPc+0xf4 [0x82292cc]
>> [9] TclInvokeStringCommand+0x6d [0x82c5145]
>> [10] /home/dimar/NAMD/NAMD_2.5_Linux-i686/namd2 [0x82f946a]
>> [11] Tcl_EvalEx+0x1cc [0x82f9b7c]
>> [12] Tcl_EvalFile+0x157 [0x82f1ce3]
>> [13] _ZN9ScriptTcl3runEPc+0x1a [0x8228b76]
>> [14] main+0x1d2 [0x80ed052]
>> [15] __libc_start_main+0xe3 [0x7b4e33]
>> [16] sinh+0x65 [0x80eaed1]
>>
>> The same runs worked fine on Fedora Core 1 on the same workstation.
>>
>> I also tried unsuccessfully to compile Namd from source on Fedora Core 3
>> (gcc-3.4.2). Charm compilation fails with the message:
>>
>> In file included from ccs-builtins.C:11:
>> ckhashtable.h: In member function `OBJ CkHashtableT<KEY, OBJ>::get(const
>> KEY&) const':
>> ckhashtable.h:302: error: `len' undeclared (first use this function)
>> ckhashtable.h:302: error: (Each undeclared identifier is reported only
>> once for each function it appears in.)
>> ckhashtable.h:304: error: there are no arguments to `entry' that
>> depend on
>> a template parameter, so a declaration of `entry' must be available
>> ckhashtable.h:304: error: (if you use `-fpermissive', G++ will accept
>> your
>> code, but allowing the use of an undeclared name is deprecated)
>> ckhashtable.h:306: error: `layout' undeclared (first use this function)
>> ckhashtable.h:310: error: there are no arguments to `inc' that depend
>> on a
>> template parameter, so a declaration of `inc' must be available
>> ckhashtable.h: In member function `OBJ& CkHashtableT<KEY,
>> OBJ>::getRef(const KEY&)':
>> ckhashtable.h:316: error: `len' undeclared (first use this function)
>> ckhashtable.h:318: error: there are no arguments to `entry' that
>> depend on
>> a template parameter, so a declaration of `entry' must be available
>> ckhashtable.h:320: error: `layout' undeclared (first use this function)
>> ckhashtable.h:322: error: there are no arguments to `inc' that depend
>> on a
>> template parameter, so a declaration of `inc' must be available
>> In file included from ccs-builtins.C:12:
>> pup.h: In member function `CkReference<T>::operator T&()':
>> pup.h:662: error: there are no arguments to `peek' that depend on a
>> template parameter, so a declaration of `peek' must be available
>> Fatal Error by charmc in directory
>> /tmp/NAMD_2.5_Source/charm/net-linux/tmp
>> Command g++ -Wno-deprecated -D__CHARMC__=1 -DCMK_OPTIMIZE=1 -O
>> -I../bin/../include -c ccs-builtins.C -o ccs-builtins.o returned error
>> code 1
>> charmc exiting...
>> make: *** [ccs-builtins.o] Error 1
>>
>> I would appreciate any suggestions.
>>
>> Thanks,
>> Ruxandra
>>
>>
>>
>>
>>
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:39:04 CST