maximum number of bonds per particle

[skne...@ameslab.gov]

Hi All,

I am working on a problem where I have one beads that is connected
(harmonic bonds) to 80+ other beads. HOOMD complains:

***Error! Exclusion list full for particle with tag: 0

After some digging through the documentation and source code I
realized that there is a 4-bonds-per-particle limit. How hard would it
be to lift this constraint?

I am running custom compiled hoomd from the svn trunk - HOOMD svnversion 1858.

Thanks!

Rastko

[Joshua Anderson]

This issue is in the roadmap as a high-priority fix for the 0.9.0
milestone, so I will be taking care of it soon.
http://trac2.assembla.com/hoomd/ticket/86

Fixing it is relatively challenging.
--------
Joshua A. Anderson, Ph.D.
Research Area Specialist Sr - Chemical Engineering Department,
University of Michigan

[skne...@ameslab.gov]

Thanks, Josh!

Well, I think I'll have to think how to set up my system without the
highly bonded particle, at least until you take care of all necessary
modifications.

Cheers,

Rastko

[Joshua Anderson]

Well, if it isn't critical in your system to ignore the pair forces
between bonded particles, you could just comment out the
copyExclusionsFromBonds() that sets up those exclusions. That would at
least get you up and running to play with the system.

--------
Joshua A. Anderson, Ph.D.
Research Area Specialist Sr - Chemical Engineering Department,
University of Michigan

[skne...@ameslab.gov]

Josh, many thanks for this suggestion. I think I'll do it, as I really
don't care if extra pair forces are calculated. The energy will be
off, but at the moment I am after the structure, and I don't care much
about the observables.

[skne...@ameslab.gov]

Hi All,

This seems to be a general GCC 4.4 vs. CUDA problem.

I have just upgraded to Fedora 11 (it killed the MBR on one of my
boxes, but that is a totally different story) which comes with GCC 4.4.

If I try to compile HOOMD, or any of NVIDIA_CUDA_SDK examples (both
CUDA 2.1 and CUDA 2.2) I get the following error message:

/opt/cuda/bin/../include/math_functions.h:404: error: inline function
?int __signbit(double)? cannot be declared weak
/opt/cuda/bin/../include/math_functions.h:409: error: inline function
?int __signbitf(float)? cannot be declared weak
/usr/include/bits/mathcalls.h:350: error: inline function ?int
__signbit(double)? cannot be declared weak
/usr/include/bits/mathcalls.h:350: error: inline function ?int
__signbitf(float)? cannot be declared weak
/usr/include/bits/mathcalls.h:350: error: inline function ?int
__signbitl(long double)? cannot be declared weak
/usr/include/bits/mathinline.h:36: error: inline function ?int
__signbitf(float)? cannot be declared weak
/usr/include/bits/mathinline.h:42: error: inline function ?int
__signbit(double)? cannot be declared weak
/usr/include/bits/mathinline.h:48: error: inline function ?int
__signbitl(long double)? cannot be declared weak
/opt/cuda/bin/../include/math_functions.h:434: error: inline function
?int __signbitl(long double)? cannot be declared weak

Apparently, GCC 4.4 does not like weak declarations (whatever they
might mean).

Cheers,

Rastko

[skne...@ameslab.gov]

Josh,

I am trying to compile HOOMD revision 1878 on my old Linux box.

It fails with the following error message:

/home/sknepnek/work/hoomd/src/computes/NeighborList.cc: In member
function ?void NeighborList::addOneFourExclusionsFromTopology()?:
/home/sknepnek/work/hoomd/src/computes/NeighborList.cc:798: error:
?class ParticleData? has no member named ?getBondData?

Thanks,

Rastko

[Joshua Anderson]

Indeed. NVIDIA only added support for systems with gcc 4.3 a month ago.

Fedora 11 has only been out for one day, so it makes sense that NVIDIA
doesn't support it for CUDA.

One possible workaround that many users have reported success with on
the CUDA forums (at least with newer ubuntus) is to just install and
use the old version of gcc.

--------
Joshua A. Anderson, Ph.D.
Research Area Specialist Sr - Chemical Engineering Department,
University of Michigan

[Joshua Anderson]

Update from NVIDIA on this:
http://forums.nvidia.com/index.php?s=&showtopic=99139&view=findpost&p=551731

So Fedora 11 will not be supported in CUDA 2.3, but will be in
following release.

I will support any CPU compilation issues on any recent version of any
C++ compiler, but enabling CUDA locks me into supporting only those
operating systems that NVIDIA supports. If you want a good resource
for finding workarounds to get CUDA working on unsupported systems,
see http://forums.nvidia.com/index.php?showforum=68

One exception: Gentoo is unsupported by NVIDIA, but it is my primary
OS so I support problems on Gentoo by default :) Things are simple on
gentoo, though: just emerge nvidia-cuda-toolkit and you are good to go.

--------
Joshua A. Anderson, Ph.D.
Research Area Specialist Sr - Chemical Engineering Department,
University of Michigan

[Axel]

On Jun 12, 10:15 am, Joshua Anderson <joaan...@umich.edu> wrote:
> Update from NVIDIA on this:http://forums.nvidia.com/index.php?s=&showtopic=99139&view=findpost&p...

>
> So Fedora 11 will not be supported in CUDA 2.3, but will be in
> following release.

which means the best intermediate solution would be to have a
set of compat-gcc43 packages, analogous to the compat-gcc33.
i may be compelled to produce those to be able to provide RPM packages
with CUDA support for the pending VMD-1.8.7 release which will also
is slated to support loading VMD as a python module into python
interpreters, e.g. HOOMD.

if i find the time (which is the biggest problem right now), having
a similarly built "native" HOOMD rpm would be not so much additional
effort.

cheers,
axel.

> I will support any CPU compilation issues on any recent version of any
> C++ compiler, but enabling CUDA locks me into supporting only those
> operating systems that NVIDIA supports. If you want a good resource
> for finding workarounds to get CUDA working on unsupported systems,

> seehttp://forums.nvidia.com/index.php?showforum=68

>
> One exception: Gentoo is unsupported by NVIDIA, but it is my primary
> OS so I support problems on Gentoo by default :) Things are simple on
> gentoo, though: just emerge nvidia-cuda-toolkit and you are good to go.
> --------
> Joshua A. Anderson, Ph.D.
> Research Area Specialist Sr - Chemical Engineering Department,
> University of Michigan
>
> On Jun 10, 2009, at 2:09 PM, Joshua Anderson wrote:
>
>
>
>
>
>
>
> > Indeed. NVIDIA only added support for systems with gcc 4.3 a month
> > ago.
>
> > Fedora 11 has only been out for one day, so it makes sense that NVIDIA
> > doesn't support it for CUDA.
>
> > One possible workaround that many users have reported success with on
> > the CUDA forums (at least with newer ubuntus) is to just install and
> > use the old version of gcc.
> > --------
> > Joshua A. Anderson, Ph.D.
> > Research Area Specialist Sr - Chemical Engineering Department,
> > University of Michigan
>

[Axel]

On Jun 12, 10:15 am, Joshua Anderson <joaan...@umich.edu> wrote:

> Update from NVIDIA on this:http://forums.nvidia.com/index.php?s=&showtopic=99139&view=findpost&p...

>
> So Fedora 11 will not be supported in CUDA 2.3, but will be in
> following release.

after some digging around in the hoomd sources and cuda headers,
it looks as if there is a workaround for the time being, that would
make at least HOOMD compilable with gcc-4.4 and cuda-2.2:

all that would need to be done is to take the file
$CUDA_HOME/include/math_functions.h, and edit the code
around lines 400-430 to either remove the __host__ macro from
the 'extern __host__ __device__ __signbit{,l,d}()' declarations
or comment out those lines completely. HOOMD does not use signbit()
directly and it looks as if it is not used indirectly either.

hope that helps,
axel.
>

[Rastko Sknepnek]

Axel,

This is a great suggestion! I'll definitively give it a shot.

However, what worries me a bit is the following error (compilation of, e.g, nbody in NVIDIA_CUDA_SDK as well as of HOOMD):

/usr/include/bits/mathcalls.h:350: error: inline function ‘int __signbit(double)’ cannot be declared weak

since:

yum whatprovides /usr/include/bits/mathcalls.h

tells me:

Loaded plugins: dellsysidplugin2, refresh-packagekit
Importing additional filelist information
glibc-headers-2.10.1-2.x86_64 : Header files for development using standard C libraries.
Repo        : fedora
Matched from:
Filename    : /usr/include/bits/mathcalls.h



glibc-headers-2.10.1-2.x86_64 : Header files for development using standard C libraries.
Repo        : installed
Matched from:
Other       : Provides-match: /usr/include/bits/mathcalls.h

This seems to be coming as a part of glibc-headers. I am guessing that __host__ macro in $CUDA_HOME/include/math_functions.h somehow makes int __signbit(double) in /usr/include/bits/mathcalls.h weak (again, I have no clue what a "weak" declaration actually means).

Many thanks,

Rastko

[Axel]

On Jun 13, 6:35 pm, Rastko Sknepnek <sknep...@ameslab.gov> wrote:
> Axel,
>
> This is a great suggestion! I'll definitively give it a shot.

[...]

> This seems to be coming as a part of glibc-headers. I am guessing that
> __host__ macro in $CUDA_HOME/include/math_functions.h somehow makes int
> __signbit(double) in /usr/include/bits/mathcalls.h weak (again, I have

there are many (re-)declarations in this header. and declaring
those symbols as weak is a convenient way to provide a consistent
programming environment without have a myriad of ifdefs for all
kinds of compiler and library versions.

> no clue what a "weak" declaration actually means).

a "weak symbol" is a compiled object (function, method, static
variable)
that is only used if there is no other definition of it. usually it
is
an error to have two "external" symbols of the same name if they are
not
identical. declaring a symbol to be "weak" allows to provide a
fallback
implementation that is only used, if the host does not provide it.

having weak symbols as inline functions doesn't make too much sense,
(since those will be inserted regardless) and it looks as if gcc-4.4
now recognizes this case and flags it as an error.

cheers,
axel.

[Rastko Sknepnek]

Axel,

Many thanks for the nice explanation about "weak symbols".

I have tried your suggested work-around and it helped. HOOMD (together with most NVIDIA examples) compiles and runs without any problems on Fedora 11 (GCC 4.4 and Python 2.6)!

Here is a patch (output of diff $CUDA_HOME/include/math_functions.h.original $CUDA_HOME/include/math_functions.h) that did the trick:

404c404
< extern __host__ __device__ int           __signbit(double) __THROW;
---
> extern __device__ int           __signbit(double) __THROW;
409c409
< extern __host__ __device__ int           __signbitf(float) __THROW;
---
> extern __device__ int           __signbitf(float) __THROW;
434c434
< extern __host__ __device__ int __signbitl(long double) __THROW;
---
> extern __device__ int __signbitl(long double) __THROW;

Best,

Rastko

[Rastko Sknepnek]

Josh,

I cannot find copyExclusionsFromBonds(), but I have found addExclusionsFromBonds(). I assume that is what you meant.

If I try to comment it out:

line 304 in $HOOMD_HOME/src/lib/python-module/hoomd_script/pair.py

self.cpp_nlist.addExclusionsFromBonds();

HOOMD stops complaining about too many bonds and runs without any problems.

Many thanks!

Rastko

[Joshua Anderson]

when I sent the original message, it was copy. It has been changed to
add when I setup the code to allow the different exclusions to be
chosen orthogonally.

--------
Joshua A. Anderson, Ph.D.
Research Area Specialist Sr - Chemical Engineering Department,
University of Michigan

[Rastko Sknepnek]

Josh,

Many thanks for the clarification. That is what I've guessed, but I just wanted to make sure.

Just a pedantic remark, in lines 96 and 98 (a documentation comment) of src/computes/NeighborList.h, copyExclusionsFromBonds() is still mentioned.

Best,

Rastko