Q:

I like your paper about 3V tool and I try to apply it on my proteins. However there seems to be a problem with online version – I cannot get to results through the link provided, e.g. http://geometry.molmovdb.org/3v/tempfiles/nchan8269.pdb.gz

I tried both module for cavities and channels with similar failure.

Could you solve it for me please?

A:
I’ve set up a newer server that provides more feedback at http://3vee.molmovdb.org, I keep the old one around since people still prefer it.

All I can tell from looking at the server is that the file you are looking to download does not exist. So, maybe the program crashed. Try the new site and it might be more informative.

I would try Channel Finder instead of Channel Extraction. Channel Extraction is very particular about finding the exact coordinate of the channel — in fact I may change the algorithm to accommodate for this.

Q:
I download Voss Volume Voxelator from website
http://3vee.molmovdb.org/sourcecode.php. When I open the source of 3v, and
then use "make" to compile all the source. but the err happen as below:

####################################################################
cpuflags: cpuflags : unknown Intel Pentium3 model "42"
g++ -Wall -O3 -fomit-frame-pointer -ffast-math -funroll-loops -march=i686
-fopenmp -c -o utils-main.o utils-main.cpp
utils-main.cpp:1:0: error: CPU you selected does not support x86-64
instruction set
make: *** [utils-main.o] Error 1
####################################################################

I use "uame -a", and the specify information:
**********************************************************************************
Linux localhost.localdomain 2.6.35.6-45.fc14.x86_64
#1 SMP Mon Oct 18 23:57:44 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
**********************************************************************************

What’s wrong with the compile of 3v program? Could you give me some
suggestion?

A:
Could you download the the latest subversion it should fix your problem:

svn checkout http://vossvolvox.svn.sourceforge.net/svnroot/vossvolvox/ vossvolvox/

Q:

I run into a problem using your 3v tool for the shell. I am using Mac OS X 10.6 with Xcode installed. During compiling I get the following warnings: cpuflags: CPU "core" not supported by compiler "gcc-2335.9" on Darwin g++ -Wall -O3 -fomit-frame-pointer -ffast-math -funroll-loops -fopenmp -o AllChannel.exe utils-main.o utils-output.o utils-mrc.o allchannel.cpp allchannel.cpp: In function ‘int main(int, char**)’: allchannel.cpp:57: warning: format not a string literal and no format arguments allchannel.cpp:67: warning: format not a string literal and no format arguments allchannel.cpp:73: warning: format not a string literal and no format arguments chmod 755 AllChannel.exe mv AllChannel.exe ../bin for all tools in the package. I was trying using the volume tool and I compared it with your web service. Both generated the same result without any error message. Then I moved on and tried screening for channels. This time however the script crashes with the message segmentation fault (command used ../bin/AllChannel.exe -b 12.000 -s 1.400 -t 1.500 -g 0.500 -v 700 -i 2RH2_WT67_model1-noions.xyzr 2> output.log). I compared it with the console output from the web service. Until the segmentation fault both outputs (local and web) are exactly the same. Do you have any idea what might cause the problem.

A:
I compiled it on a mac once, but it has been a while. My guess is that you do not have openMP installed on your mac (a simple library that allows multiprocessor support).

Go into the Makefile (it is a text file) and change the FLAGS line at the top to just:

FLAGS = -Wall

then try it again. Let me know if it works or not.

From what I can tell you are not using openmp, library named libgomp. If you use ‘top -s3
-ocpu’, can you tell if it is using more than 100%.

Ok, back to the seg fault. I have no idea, like you said it is the exact same command. I can see that it dies somewhere between line 180 and 300, but it does not run lines 202-266.

Can you go into utils.h and change the DEBUG flag to 1

#define DEBUG 1

then compile and run it again.

Also – Did you do a ‘make clean’ before compiling after changing the DEBUG flag? Because there should be a lot more output.

Another thing to try is slightly adjusting the grid size (go from 0.5 to 0.51), to see if it is trying to access memory outside the bounds of the array.

Q:
I am writing about your article, The Packing Density in Proteins: Standard Radii and Volumes, published by JMB on 1999. In the article, in particular in table 2, you list a series of radii associated to each atom according to the number of hydrogens it has attached and a number you call the “valence”. However, valences of carbon are 2 and 4, and the list shows a valence 3 carbon; also valences for nitorgen are 3 and 5, and the tible shows a valence 4 one. Could you please explain what you mean by the term “valence” exactly? In particular, I am interested in knowing the type of heavy atoms you can find in glutamine and alanine residues, and their radii.

A:
Here, the term “valence” is perhaps best described in Table 1 (instead of Table 2). What is meant by the “n-term” (here, used synonymously with valence) is usually a geometric descriptor designating the orientation of other atomic species around that atom (for example, n=4 usually means that the atom builds a tetrahedron, whereas n=3 usually means that the atom is trigonal planar). Strictly speaking, and perhaps more accurately, n just designates the total number of atoms bound to a central atom. So, in your example of carbon’s n=3 in Table 2, these are carbon atoms which are connected to 3 other atoms (an example of C3H0 may be the carbonyl carbon in a protein backbone, and C3H1 may be a carbon atom in a phenyl group of PHE). In your example of nitrogen’s n=4, the N4H3 may represent the epsilon-amino group in LYS, since it is bound to 4 other atoms (one carbon and 3 hydrogen atoms).

Q.
I am experiencing problems in trying to compile your package (libproteingeometry-2-3-1). I tried to compile it under Ubuntu-11.10 on a 32-bit VAIO centrino-based PC (gcc vers 4.6.1) and I got the following error message:

utypes.h:16:15: error: conflicting types for ‘float_t’
/usr/include/i386-linux-gnu/bits/mathdef.h:36:21: note: previous declaration of
‘float_t’ was here

Is it possible that this error is related CPPFLAGS settings?

I have also had difficulty compiling on an Intel i7 64-b machine under Ubuntu-11.10 with the same gcc version. This time the message was:

../src-lib/.libs/libproteingeometry: undefined reference to `sincos’ ../src-lib/.libs/libproteingeometry: undefined reference to `ceil’ ../src-lib/.libs/libproteingeometry: undefined reference to `atan2′ ../src-lib/.libs/libproteingeometry: undefined reference to `acos’ ../src-lib/.libs/libproteingeometry: undefined reference to `sin’ ../src-lib/.libs/libproteingeometry: undefined reference to `rint’ ../src-lib/.libs/libproteingeometry: undefined reference to `sqrtf’ ../src-lib/.libs/libproteingeometry: undefined reference to `pow’ ../src-lib/.libs/libproteingeometry: undefined reference to `sqrt’ ../src-lib/.libs/libproteingeometry: undefined reference to `floor’ collect2: ld returned 1 exit status

A.
This problem was resolved in a strange way. The package was compiled in the /usr/local dir of an Intel i5 machine, and all the compiled material was brought to the corresponding dir of an i7 computer. Almost the same had been done for a vaio 32-bit computer using a CD with the Ubuntu 9.10 version on another 32-bit system.

There may have been some collisions with environment flags set by the preceding compilation of other packages. In particular, Amber10 and Gromacs-4-5-5 had already been installed on the i7 and vaio.