Menu
▾
▴
cdk-devel
|
From: Rajarshi G. <rx...@ps...> - 2005-05-08 22:36:50
|
Hi, this is more of a Java question than a CDK one:
I've written the code for evaluating accessible atomic surface areas and
it depends on a tessellation class. So my source file looks like:
public class NumericalSurface {
public NumericalSurface() {
}
}
class Tessellate {
public Tessellate() {
}
}
When I compile it into the CDK and then write a program that
instantiates NumericalSurface, the program compiles fine.
However running it gives me the error:
Exception in thread "main" java.lang.NoClassDefFoundError:
org/openscience/cdk/geometry/surface/Tessellate
at
org.openscience.cdk.geometry.surface.NumericalSurface.calculateSurface
(NumericalSurface.java:115)
at surftest.main(surftest.java:48)
Placing the Tessellate class within the NumericalSurface class makes it
all work fine.
I'm confused because when I was writing the code as a standalone
program, the NumericalSurface class was able to instantiate the
Tessellation class when it was written in the first way (above).
I thought that if I had multiple classes in a single file, then only the
public class would be visible and all other classes in the file would be
visible only by this public class.
I can always place the Tessellate class (and some other) classes in the
surface class, but it then the surface class becomes very unwieldy.
Any pointers would be appreciated.
-------------------------------------------------------------------
Rajarshi Guha <rx...@ps...> <http://jijo.cjb.net>
GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE
-------------------------------------------------------------------
All the passions make us commit faults; love makes us commit the most
ridiculous ones.
-- La Rochefoucauld
|
|
From: Christoph S. <c.s...@un...> - 2005-05-09 07:51:42
|
Rajarshi Guha wrote: > I thought that if I had multiple classes in a single file, then only th= e > public class would be visible and all other classes in the file would b= e > visible only by this public class. Still, all the classes defined in this single *.java file should end up=20 as discrete .class files eventually. You mail doesn't say anything about the mechanism by which you run the=20 program, beside your statement that you "compile it into the CDK". So, first I would do a "jar tvf cdk-blah.jar | grep Tessellate" on the=20 all the cdk-jars in your class path. did you add a CDK module tag to the classes header? Maybe the two=20 classes ended up in to different modules and you only included one of=20 them in your classpath. Sorry, just random thoughts. Cheers, Chris --=20 Priv. Doz. Dr. Christoph Steinbeck (c.s...@un...) Head of the Research Group for Molecular Informatics Cologne University BioInformatics Center (http://www.cubic.uni-koeln.de) Z=FClpicher Str. 47, 50674 Cologne Tel: +49(0)221-470-7426 Fax: +49 (0) 221-470-7786 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
|
From: Peter Murray-R. <pm...@ca...> - 2005-05-09 10:02:17
|
At 08:38 09/05/2005, Christoph Steinbeck wrote: >Rajarshi Guha wrote: > >>I thought that if I had multiple classes in a single file, then only the >>public class would be visible and all other classes in the file would be >>visible only by this public class. > >Still, all the classes defined in this single *.java file should end up as= =20 >discrete .class files eventually. >You mail doesn't say anything about the mechanism by which you run the=20 >program, beside your statement that you "compile it into the CDK". >So, first I would do a "jar tvf cdk-blah.jar | grep Tessellate" on the all= =20 >the cdk-jars in your class path. >did you add a CDK module tag to the classes header? Maybe the two classes= =20 >ended up in to different modules and you only included one of them in your= =20 >classpath. > >Sorry, just random thoughts. In the early days of Java there could be a problem with Applets for classes= =20 which were not public. I doubt this is your problem, however. Generally I=20 find that nay substantive class is better in its own file and normally only= =20 have very small ones in this way. P. >Cheers, > >Chris > >-- >Priv. Doz. Dr. Christoph Steinbeck (c.s...@un...) >Head of the Research Group for Molecular Informatics >Cologne University BioInformatics Center (http://www.cubic.uni-koeln.de) >Z=FClpicher Str. 47, 50674 Cologne >Tel: +49(0)221-470-7426 Fax: +49 (0) 221-470-7786 > >What is man but that lofty spirit - that sense of enterprise. >... Kirk, "I, Mudd," stardate 4513.3.. > > >------------------------------------------------------- >This SF.Net email is sponsored by: NEC IT Guy Games. >Get your fingers limbered up and give it your best shot. 4 great events, 4 >opportunities to win big! Highest score wins.NEC IT Guy Games. Play to >win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 >_______________________________________________ >Cdk-devel mailing list >Cdk...@li... >https://lists.sourceforge.net/lists/listinfo/cdk-devel Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 Fax: +44 1223 763076 |
|
From: Rajarshi G. <rx...@ps...> - 2005-05-09 15:51:20
|
On Mon, 2005-05-09 at 09:38 +0200, Christoph Steinbeck wrote: > Rajarshi Guha wrote: > > > I thought that if I had multiple classes in a single file, then only the > > public class would be visible and all other classes in the file would be > > visible only by this public class. > > Still, all the classes defined in this single *.java file should end up > as discrete .class files eventually. > You mail doesn't say anything about the mechanism by which you run the > program, beside your statement that you "compile it into the CDK". I placed the surface class in the CDK hierarchy and then recompiled the CDK. In the final cdk-extra.jar file, the only class was the surface class, the helper classes did not get included > So, first I would do a "jar tvf cdk-blah.jar | grep Tessellate" on the > all the cdk-jars in your class path. > did you add a CDK module tag to the classes header? Maybe the two > classes ended up in to different modules and you only included one of > them in your classpath. Thanks for the pointers. As long as the helper classes were in the same file as the surface class, they were not being collected in the jars, even when the cdk.module tag was specified for each class. What I did was to make each class a seperate file. This makes everything work. The problem with this approach is that each of these classes needs to be public - otherwise the build process does not include them while makinmg the jar files. Though this is not generally a problem, some classes (such as a NeighborList class) are really only required for the surface class and hence have no need to be public. If I understand correctly, a class X in a package P can access a non- public class Y in the same package. But unless I make each class public the build process is not including them. Does anybody have any idea as to whats going on? (Is it OK for me to upload the code to CVS - the code works fine, I'm just unsure of whats going on in the build process) Thanks, ------------------------------------------------------------------- Rajarshi Guha <rx...@ps...> <http://jijo.cjb.net> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- Artificial intelligence has the same relation to intelligence as artificial flowers have to flowers. -- David Parnas |
|
From: Rajarshi G. <rx...@ps...> - 2005-05-09 21:25:11
|
On Mon, 2005-05-09 at 11:51 -0400, Rajarshi Guha wrote: > On Mon, 2005-05-09 at 09:38 +0200, Christoph Steinbeck wrote: > > Rajarshi Guha wrote: > > > > > I thought that if I had multiple classes in a single file, then only the > > > public class would be visible and all other classes in the file would be > > > visible only by this public class. > > > > Still, all the classes defined in this single *.java file should end up > > as discrete .class files eventually. > > You mail doesn't say anything about the mechanism by which you run the > > program, beside your statement that you "compile it into the CDK". After looking at build.xml I see that the reallyRunDoclet task, creates the *.javafiles by considering classes that are designated public. As a result, if I place the surface class in a file and designate it public and also include the other classes in the same file, but with no access qualifier, then the build process will place the surface class *only* in the extra.javafiles (I specified that the surface class should be in the cdk-extra module via cdk.tag). Even if I split up each class into its own file, unless they are all specified as public the ant task does not place them in extra.javafiles. I realize that the documention should only produce docs for public classes and methods, but it also seems to result in non-public classes not being included for compilation. I'm sure I'm missing something here, but I can't seem to see how to fix this problem. ------------------------------------------------------------------- Rajarshi Guha <rx...@ps...> <http://jijo.cjb.net> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- "355/113 -- Not the famous irrational number PI, but an incredible simulation!" |
|
From: Egon W. <eg...@us...> - 2005-05-10 05:36:36
|
On Monday 9 May 2005 00:36, Rajarshi Guha wrote: > I've written the code for evaluating accessible atomic surface areas and > it depends on a tessellation class. Rajarshi, what does this actually do? Does it calculate triangles given as set of points in space? If not, with what information does it start, and what thus is calculate in which order to achieve the surface? Egon -- eg...@us... GPG: 1024D/D6336BA6 |
|
From: Rajarshi G. <rx...@ps...> - 2005-05-10 13:10:42
|
On Tue, 2005-05-10 at 07:36 +0200, Egon Willighagen wrote: > On Monday 9 May 2005 00:36, Rajarshi Guha wrote: > > I've written the code for evaluating accessible atomic surface areas and > > it depends on a tessellation class. > > Rajarshi, what does this actually do? Calculates the solvent accessible surface area (or van der waals surface area if solvent radius is set to 0) to the atoms in a molecule and hence the total surface area of a molecule > Does it calculate triangles given as set of points in space? If not, with what > information does it start, and what thus is calculate in which order to > achieve the surface? It's based on the simplified version of the DCLM method by Eisenhaber et al. (J. Comp. Chem., 19995, 16, 273-284) described by Peter McCluskey in the MMTK. I modified it from the version described by McCluskey to generate points on the surface by starting from the tessellation of a unit icosahedron. The points are generated by recursive subdivision and the point density is'nt limited to the form implemented by McCluskey. Given that its a numerical algorithm rather than an analytical algorithm its not exact. However the results for two test molecules compared to the SAVOL program by Pearlman (which is analytical) and PyMOL, ppear to be decent: /* Solvent radius = 1.4A * * this pearlman(savol) pymol (on the PDB file) * gravindex.hin 461.67 459.48 445.55 * surftst.hin 268.09 274.37 262.69 */ ------------------------------------------------------------------- Rajarshi Guha <rx...@ps...> <http://jijo.cjb.net> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- A computer lets you make more mistakes faster than any other invention, with the possible exceptions of handguns and Tequilla. -- Mitch Ratcliffe |
|
From: Egon W. <eg...@us...> - 2005-05-10 05:43:44
|
On Monday 9 May 2005 23:25, Rajarshi Guha wrote: > On Mon, 2005-05-09 at 11:51 -0400, Rajarshi Guha wrote: > > On Mon, 2005-05-09 at 09:38 +0200, Christoph Steinbeck wrote: > I realize that the documention should only produce docs for public > classes and methods, but it also seems to result in non-public classes > not being included for compilation. That's a short coming of the build process... the runDoclet uses JavaDoc, and thus has such flaws... I've worked around this by extending all classes in src/*.classes for all inner classes, though... e.g. org/openscience/cdk/atomtype/AtomTypeMatcher*.class This includes inner classes which have a class name like: org/openscience/cdk/atomtype/AtomTypeMatcher$SomeInnerClass.class > I'm sure I'm missing something here, but I can't seem to see how to fix > this problem. I saw a commit, so I guess to got it figurered out, but I am looking around for a Java+JavaDoc parser , or grammar, or so, so that I can replace the use of JavaDoc in runDoclet altogether... anyone suggestions? Egon -- eg...@us... GPG: 1024D/D6336BA6 |
|
From: Rajarshi G. <rx...@ps...> - 2005-05-10 13:03:57
|
On Tue, 2005-05-10 at 07:43 +0200, Egon Willighagen wrote: > On Monday 9 May 2005 23:25, Rajarshi Guha wrote: > > On Mon, 2005-05-09 at 11:51 -0400, Rajarshi Guha wrote: > > > On Mon, 2005-05-09 at 09:38 +0200, Christoph Steinbeck wrote: > > I realize that the documention should only produce docs for public > > classes and methods, but it also seems to result in non-public classes > > not being included for compilation. > > That's a short coming of the build process... the runDoclet uses JavaDoc, and > thus has such flaws... I've worked around this by extending all classes in > src/*.classes for all inner classes, though... > > e.g. org/openscience/cdk/atomtype/AtomTypeMatcher*.class > > This includes inner classes which have a class name like: > > org/openscience/cdk/atomtype/AtomTypeMatcher$SomeInnerClass.class > > > I'm sure I'm missing something here, but I can't seem to see how to fix > > this problem. > > I saw a commit, so I guess to got it figurered out, but I am looking around > for a Java+JavaDoc parser , or grammar, or so, so that I can replace the use > of JavaDoc in runDoclet altogether... anyone suggestions? Well, actually I did'nt get it figured out - I realized that public class which have helper classes in the form of inner classes are handled fine (as you point out above). But since the code was working, I put it in. Since the helper classes for the surface class are quite large, making them inner classes makes the surface class quite unwieldy. So for now, I've made them all public. Would this approach be feasible? Basically make the runDoclet task run with private="true" for compilation, so that al Java source files get placed in *.javafiles. Then make another task, runDoclet2, say, with the private="false" when the documentation is to be generated? (I realize that it would just slow down the build process) ------------------------------------------------------------------- Rajarshi Guha <rx...@ps...> <http://jijo.cjb.net> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- Cogito cogito ergo cogito sum (I think that I think, therefore I think that I am.) -- Ambrose Bierce |
|
From: Egon W. <eg...@us...> - 2005-05-10 13:28:30
|
On Tuesday 10 May 2005 03:10 pm, Rajarshi Guha wrote: > On Tue, 2005-05-10 at 07:36 +0200, Egon Willighagen wrote: > > Does it calculate triangles given as set of points in space? If not, with > > what information does it start, and what thus is calculate in which order > > to achieve the surface? > > It's based on the simplified version of the DCLM method by Eisenhaber et > al. (J. Comp. Chem., 19995, 16, 273-284) described by Peter McCluskey in > the MMTK. I ask this, because with Jmol we have the problem that we have a surface defined by points in space. But no connectivity. Therefore, the Jmol project needs an implementation that can convert this set of unconnected points into a set of points where all points have three neighbors on the surface, i.e. triangles are defined for that surface. Egon |
|
From: Rajarshi G. <rx...@ps...> - 2005-05-10 13:54:31
|
On Tue, 2005-05-10 at 15:25 +0200, Egon Willighagen wrote: > On Tuesday 10 May 2005 03:10 pm, Rajarshi Guha wrote: > > On Tue, 2005-05-10 at 07:36 +0200, Egon Willighagen wrote: > > > Does it calculate triangles given as set of points in space? If not, with > > > what information does it start, and what thus is calculate in which order > > > to achieve the surface? > > > > It's based on the simplified version of the DCLM method by Eisenhaber et > > al. (J. Comp. Chem., 19995, 16, 273-284) described by Peter McCluskey in > > the MMTK. > > I ask this, because with Jmol we have the problem that we have a surface > defined by points in space. But no connectivity. Therefore, the Jmol project > needs an implementation that can convert this set of unconnected points into > a set of points where all points have three neighbors on the surface, i.e. > triangles are defined for that surface. Hmm, the algorithm uses a tessellation of a unit sphere, but when calculating the surface, it drops the triangle representaiton and only considers a series of points, some of which will be dropped due to occlusion. So the triangle info gets lost Mesh generation seems to be a tough problem! Heres a page of links I came across which might be useful: http://www-2.cs.cmu.edu/~ph/mesh.html ------------------------------------------------------------------- Rajarshi Guha <rx...@ps...> <http://jijo.cjb.net> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- All laws are simulations of reality. -- John C. Lilly |
|
From: Rajarshi G. <rx...@ps...> - 2005-05-10 14:05:02
|
On Tue, 2005-05-10 at 09:54 -0400, Rajarshi Guha wrote: > On Tue, 2005-05-10 at 15:25 +0200, Egon Willighagen wrote: > > I ask this, because with Jmol we have the problem that we have a surface > > defined by points in space. But no connectivity. Therefore, the Jmol project > > needs an implementation that can convert this set of unconnected points into > > a set of points where all points have three neighbors on the surface, i.e. > > triangles are defined for that surface. > > Hmm, the algorithm uses a tessellation of a unit sphere, but when > calculating the surface, it drops the triangle representaiton and only > considers a series of points, some of which will be dropped due to > occlusion. So the triangle info gets lost > > Mesh generation seems to be a tough problem! Heres a page of links I > came across which might be useful: Just as a followup, I cam across a paper and Matlab code that is pretty well explained. (It requires that you have a Delaunay triangulation function though) http://www-math.mit.edu/~persson/mesh/ ------------------------------------------------------------------- Rajarshi Guha <rx...@ps...> <http://jijo.cjb.net> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- So the Zen master asked the hot-dog vendor, "Can you make me one with everything?" - TauZero on Slashdot |
Thanks for helping keep SourceForge clean.
X