Menu
▾
▴
joelib-help — JOELib-Help
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(4) |
May
(1) |
Jun
(10) |
Jul
(1) |
Aug
(14) |
Sep
(4) |
Oct
(1) |
Nov
(11) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(5) |
Feb
(14) |
Mar
(21) |
Apr
(7) |
May
(8) |
Jun
(18) |
Jul
(14) |
Aug
(21) |
Sep
(4) |
Oct
(10) |
Nov
(8) |
Dec
(12) |
| 2005 |
Jan
(7) |
Feb
(9) |
Mar
(2) |
Apr
(8) |
May
(11) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2006 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2007 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joerg K. W. <we...@in...> - 2004-08-27 14:45:10
|
Dear JEAN-YVES,
> I'm still not exactly where I want with the joelib.
> I would like to generate a Text file with the native value descriptors
> corresponding to the structures in the SDF file.
> Running : sh convert.sh +d -oFLAT examples.SDF out.FLAT (I guess FLAT
> should be the correct format)
> Returns a file without any descriptors? (for the moment ,I get the results
> of the descriptor calculations only when choosing .SDF as output format.
> When running sh calculateDescriptor.sh +jcc examples.SDF out.FLAT
> It returns an error message (even when adding -ap -SSKey).
> -oFLAT seems also not to be recognized as a valid option.
Yes and no.
There are only 2 and 1/2 file formats which supports all possible
descriptor types in JOELib, like values, arrays, matrices, atom-pairs
and all the other stuff.
These file formats are:
SDF (import/export)
CML (import/export)
CTX (import only, CACTVS format of
Wolf-Dietrich-Ihlenfeldt, Xchemistry GmbH
Prof. Gasteiger, Molecular Networks)
So it is clear that it makes no sense to store all kind of descriptors
in a flat file.
This explains your problems. Three solutions:
1. the default conversion mechanism requires a definition of the things
to convert, so e.g. the SMILES and FLAT format have its definitions in
joelib.properties.
If you want to change these settings you must change these properties
there or you can change them by using the command line options.
I've added this option for the conversion mechanism only to the
ConvertSkip-class, for which the shell script is convertSkip.sh
Here are the options and don't forget to quote these definitions.
[+f<lineStructure>] - Required if you use FLAT output format which
other input format
[+ff<lineStructureFile>]- Required if you use FLAT output format which
other input format
[+s<lineStructure>] - Can be used for an alternate SMILES entry
line structure
2. Use sh descSelection.sh
with flat-option and your preferred delimiter, this will be more or less
analogue, but faster than the convertSkip routine.
3. Developer way. Calculate only the descriptors you need, so you can
avoid temporary files :-)
For hints see the tutorial and all examples in joelib/test or write me
an additional mail using the developer mailing list, then i can go into
details. But the code i will give you there will be really similar to
code fragments you can find in the joelib/test package.
Kind regards, Joerg
>
> Best regards
>
> Jean-Yves
>
>
> error message:
>
> USING DEFAULT_ATOM_PROPERTIESUSING DEFAULT_ATOM_PROPERTIES15:50:36 [INFO ]
> joelib.test.DescriptorCalculation - ... 115 molecules successful
> calculated in 242794 ms.15:50:36 [INFO ] joelib.test.DescriptorCalculation
> - Calculate binary SMARTS and fingerprints...15:50:36 [ERROR]
> joelib.io.types.MDLSD - Can not convert string 'Mol' to
> type 'int' in line: Molecule 2joelib.io.MoleculeIOException: Error in
> atom/bond definition line. at
> joelib.io.types.MDLSD.readNumbers(MDLSD.java:1586) at
> joelib.io.types.MDLSD.read(MDLSD.java:312) at
> joelib.io.types.MDLSD.read(MDLSD.java:279) at
> joelib.test.DescriptorCalculation.calculateNominalDescriptors(DescriptorCalculation.java:714)
> at
> joelib.test.DescriptorCalculation.main(DescriptorCalculation.java:110)
>
>
>
>
>
>
>
>
>
>
>
> **********************************************************************
> DISCLAIMER
> This email and any files transmitted with it, including replies and
> forwarded copies (which may contain alterations) subsequently
> transmitted from Firmenich, are confidential and solely for the use
> of the intended recipient.
> The contents do not represent the opinion of Firmenich except
> to the extent that it relates to their official business.
> **********************************************************************
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Joelib-help mailing list
> Joe...@li...
> https://lists.sourceforge.net/lists/listinfo/joelib-help
>
--
Dipl. Chem. Joerg K. Wegner
Center of Bioinformatics Tuebingen (ZBIT)
Department of Computer Architecture
Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany
Phone: (+49/0) 7071 29 78970
Fax: (+49/0) 7071 29 5091
E-Mail: mailto:we...@in...
WWW: http://www-ra.informatik.uni-tuebingen.de
--
Never mistake motion for action.
(E. Hemingway)
Never mistake action for meaningful action.
(Hugo Kubinyi,2004)
|
|
From: <JEA...@fi...> - 2004-08-27 14:22:38
|
Dear Joerg,
Thank you again for your quick answers.
I'm still not exactly where I want with the joelib.
I would like to generate a Text file with the native value descriptors
corresponding to the structures in the SDF file.
Running : sh convert.sh +d -oFLAT examples.SDF out.FLAT (I guess FLAT
should be the correct format)
Returns a file without any descriptors? (for the moment ,I get the results
of the descriptor calculations only when choosing .SDF as output format.
When running sh calculateDescriptor.sh +jcc examples.SDF out.FLAT
It returns an error message (even when adding -ap -SSKey).
-oFLAT seems also not to be recognized as a valid option.
Best regards
Jean-Yves
error message:
USING DEFAULT_ATOM_PROPERTIESUSING DEFAULT_ATOM_PROPERTIES15:50:36 [INFO ]
joelib.test.DescriptorCalculation - ... 115 molecules successful
calculated in 242794 ms.15:50:36 [INFO ] joelib.test.DescriptorCalculation
- Calculate binary SMARTS and fingerprints...15:50:36 [ERROR]
joelib.io.types.MDLSD - Can not convert string 'Mol' to
type 'int' in line: Molecule 2joelib.io.MoleculeIOException: Error in
atom/bond definition line. at
joelib.io.types.MDLSD.readNumbers(MDLSD.java:1586) at
joelib.io.types.MDLSD.read(MDLSD.java:312) at
joelib.io.types.MDLSD.read(MDLSD.java:279) at
joelib.test.DescriptorCalculation.calculateNominalDescriptors(DescriptorCalculation.java:714)
at
joelib.test.DescriptorCalculation.main(DescriptorCalculation.java:110)
**********************************************************************
DISCLAIMER
This email and any files transmitted with it, including replies and
forwarded copies (which may contain alterations) subsequently
transmitted from Firmenich, are confidential and solely for the use
of the intended recipient.
The contents do not represent the opinion of Firmenich except
to the extent that it relates to their official business.
**********************************************************************
|
|
From: Joerg K. W. <we...@in...> - 2004-08-27 11:39:04
|
Hi all, the new release is available. See ChengeLog.txt for details: https://sourceforge.net/project/shownotes.php?group_id=39708&release_id=263745 Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-08-26 12:10:03
|
Hi JEAN-YVES, fine and you've found a new bug, i've already fixed yesterday. Please download the patched source code file from http://sourceforge.net/tracker/index.php?func=detail&aid=1016810&group_id=39708&atid=425969 and replace joelib/src/joelib/desc/types/atompair/TopologicalAtomPair.java Kind regards, Joerg > > > Dear Joerg, > > > My original problem with joelib program. > Using the command convert, I was able to convert SDF structures to SMILES > formats. > When I try to calculate descriptors (using calculateDesriptors), I got an > error message. > > > I did the modif suggested (and recompile): > > Replace > -124-Object objProperty = availProperties.get(property); > > by this patch add the ==null checking: > > -123-if(availProperties==null) return null; > -124-Object objProperty = availProperties.get(property); > > > > I go further but I still get the following message: > > > Best regards and many thanks for your answer. > > Jean-Yves > > > [jyl@neptune JOELib-20040729]$ sh calculateDescriptors.sh +jcc > ../examples.sdf > > > examplesout.sdfException in thread "main" java.lang.NullPointerException > at > joelib.desc.types.atompair.TopologicalAtomPair.calculate(TopologicalAtomPair.java:250) > at > joelib.desc.types.atompair.TopologicalAtomPair.calculate(TopologicalAtomPair.java:198) > at > joelib.desc.DescriptorHelper.descFromMol(DescriptorHelper.java:248) > at joelib.desc.DescriptorHelper.descFromMol(DescriptorHelper.java:518) > at > joelib.test.DescriptorCalculation.getAndStoreDescriptor(DescriptorCalculation.java:594) > at > joelib.test.DescriptorCalculation.calculateNumericDescriptors(DescriptorCalculation.java:311) > at > joelib.test.DescriptorCalculation.main(DescriptorCalculation.java:108)[jyl@neptune > JOELib-20040729]$ more examplesout.sdf > > > > > > > > > > > > Dear JEAN-YVES, > > please use use for further correspondence one of the mailing lists to > avoid me answering questions mulitple times: > http://sourceforge.net/mail/?group_id=39708 > > I hope this is no problem with your disclaimer. > > > Have you some Idea on what can be wrong ? > As discussed yesterday on the mailing list, this is a bug fixed yesterday: > http://sourceforge.net/tracker/index.php?func=detail&aid=1015124&group_id=39708&atid=425969 > > > > >>Best regards >>Jean-Yves > > > Kind regards, Joerg > > > > > > > > ********************************************************************** > DISCLAIMER > This email and any files transmitted with it, including replies and > forwarded copies (which may contain alterations) subsequently > transmitted from Firmenich, are confidential and solely for the use > of the intended recipient. > The contents do not represent the opinion of Firmenich except > to the extent that it relates to their official business. > ********************************************************************** > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Joelib-help mailing list > Joe...@li... > https://lists.sourceforge.net/lists/listinfo/joelib-help > -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: <JEA...@fi...> - 2004-08-26 11:37:25
|
Dear Joerg,
My original problem with joelib program.
Using the command convert, I was able to convert SDF structures to SMILES
formats.
When I try to calculate descriptors (using calculateDesriptors), I got an
error message.
I did the modif suggested (and recompile):
Replace
-124-Object objProperty = availProperties.get(property);
by this patch add the ==null checking:
-123-if(availProperties==null) return null;
-124-Object objProperty = availProperties.get(property);
I go further but I still get the following message:
Best regards and many thanks for your answer.
Jean-Yves
[jyl@neptune JOELib-20040729]$ sh calculateDescriptors.sh +jcc
../examples.sdf
examplesout.sdfException in thread "main" java.lang.NullPointerException
at
joelib.desc.types.atompair.TopologicalAtomPair.calculate(TopologicalAtomPair.java:250)
at
joelib.desc.types.atompair.TopologicalAtomPair.calculate(TopologicalAtomPair.java:198)
at
joelib.desc.DescriptorHelper.descFromMol(DescriptorHelper.java:248)
at joelib.desc.DescriptorHelper.descFromMol(DescriptorHelper.java:518)
at
joelib.test.DescriptorCalculation.getAndStoreDescriptor(DescriptorCalculation.java:594)
at
joelib.test.DescriptorCalculation.calculateNumericDescriptors(DescriptorCalculation.java:311)
at
joelib.test.DescriptorCalculation.main(DescriptorCalculation.java:108)[jyl@neptune
JOELib-20040729]$ more examplesout.sdf
Dear JEAN-YVES,
please use use for further correspondence one of the mailing lists to
avoid me answering questions mulitple times:
http://sourceforge.net/mail/?group_id=39708
I hope this is no problem with your disclaimer.
> Have you some Idea on what can be wrong ?
As discussed yesterday on the mailing list, this is a bug fixed yesterday:
http://sourceforge.net/tracker/index.php?func=detail&aid=1015124&group_id=39708&atid=425969
> Best regards
> Jean-Yves
Kind regards, Joerg
**********************************************************************
DISCLAIMER
This email and any files transmitted with it, including replies and
forwarded copies (which may contain alterations) subsequently
transmitted from Firmenich, are confidential and solely for the use
of the intended recipient.
The contents do not represent the opinion of Firmenich except
to the extent that it relates to their official business.
**********************************************************************
|
|
From: Joerg K. W. <we...@in...> - 2004-08-24 16:35:01
|
Hi Andreas, i've changed the bug request to 'pending', because i can't reproduce this bug. Please send more informations and recheck your classpath if it contains the jmat-package. https://sourceforge.net/tracker/?func=detail&atid=425969&aid=1015117&group_id=39708 Kind regards, Joerg > Hi all, > > when I try to parse the SMILES 'C2CCC(C1CC1)C2' with JOELib via > > JOESmilesParser.smiToMol(mol, smiles, smiles); > > where 'mol' is a JOEMol object and 'smiles' is a String I keep getting an error: > > =============================================================================== > Exception in thread "main" java.lang.Error: Unresolved compilation problems: > Matrix cannot be resolved or is not a type > The method gMatrix(JOEMol) is undefined for the type GraphPotentials > Matrix cannot be resolved or is not a type > Matrix cannot be resolved or is not a type > The method cMatrix(JOEMol) is undefined for the type GraphPotentials > Matrix cannot be resolved or is not a type > > at joelib.desc.types.GraphPotentials.graphPotentials(GraphPotentials.java:30) > at joelib.molecule.JOEMol.findChiralCenters(JOEMol.java:4261) > at joelib.molecule.JOEAtom.isChiral(JOEAtom.java:609) > at joelib.smiles.JOEMol2Smi.createSmiString(JOEMol2Smi.java:994) > at joelib.util.database.AbstractDatabase.getSMILESHashcode(AbstractDatabase.java:173) > at joelib.molecule.JOEMol.hashCode(JOEMol.java:4905) > at joelib.molecule.JOEMol.reHash(JOEMol.java:5554) > at joelib.molecule.JOEMol.endModify(JOEMol.java:3961) > at joelib.molecule.JOEMol.endModify(JOEMol.java:3857) > at joelib.smiles.JOESmilesParser.parseSmiles(JOESmilesParser.java:1874) > at joelib.smiles.JOESmilesParser.smiToMol(JOESmilesParser.java:1910) > at joelib.smiles.JOESmilesParser.smiToMol(JOESmilesParser.java:124) > at SmilesSmartsViewer.main(SmilesSmartsViewer.java:35) > =============================================================================== > > I have been trying to find the reason and it appears to me that this error occurs especially when two rings are involved like in this example (however, I couldn't find a specific pattern to provoke the error and there are molecules with two rings where it works). > A fellow scientist using this routine told me the error occured in about 10% of the molecules he tried to view. > > Any ideas how to fix this? As our software reaches state 'testing' we should correct this :-) > We are NOT working on the latest JOELib release due to problems with upgrading (see my last posting) but with 2004-06-21 > > Greetings, > Andreas > > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Joelib-help mailing list > Joe...@li... > https://lists.sourceforge.net/lists/listinfo/joelib-help > -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-08-24 14:21:17
|
Hi Fr=E9d=E9ric, > I have tried the solution 1.3 using the command line bellow : > java -cp c:\JOELIB\lib\joelib.jar;c:\JOELIB\lib\log4j.jar;c:\JOELIB\lib= \itext-0.94.jar joelib.test.DescriptorSelection -iSDF Molecule.sdf -oSDF = foo.sdf descs.txt normal " " > But I get the error message : > -Can't load descs.txt The source code says that this file was not loaded by the=20 wsi.ra.tool.ResourceLoader helper class. > Do you have any idea ? 1. switch debugging on by setting in log4j.properties log4j.category.wsi.ra.tool.ResourceLoader=3DINFO to log4j.category.wsi.ra.tool.ResourceLoader=3DDEBUG than try again your command line. 2. might there are problems with reading-rights ? Kind regards, Joerg > Fred >=20 > -----Original Message----- > From: Joerg K. Wegner [mailto:we...@in...]=20 > Sent: Tuesday, August 24, 2004 3:56 PM > To: Fr=E9d=E9ric Ooms; JOELib help > Subject: Re: Convert help >=20 >=20 > Dear Fr=E9d=E9ric, >=20 > 1. basic and slow way: > 1.1. calculate all descriptors: > sh calculateDescriptors.sh +jcc inFile.sdf outFile.sdf >=20 > 1.2. calculate descriptor statistic to check descriptor occurence. sh s= tatistic.sh -iSDF outFile.sdf this will generate outFile.sdf.statistic ou= tFile.sdf.binning >=20 > Because BCUT depends on the molecule size, large matrix entries, e.g.=20 > Burden_modified_eigenvalues:Graph_potentials:18 (number=3Dinner=20 > topological distance) occur not for small molecules. >=20 > You should only use BCUTS where every molecule has this value, otherwis= e=20 > you should use a 'missing value'-replacing strategy, see also one of my= =20 > papers for more references: http://www-ra.informatik.uni-tuebingen.de/p= ublikationen/2004/wegner04jcicsA.html >=20 > Programs like Dragon hides this problems so they select only a specific= =20 > number of eigenvalues and uses often 0 for missing values, because the=20 > eigenvalues are sorted in decreasing order. But you can not expect that= =20 > this will give really good models, if the descriptor contains a lot of=20 > zeros. >=20 > 1.3. select descriptors > sh descSelection.sh -iSDF outFile.sdf -oSDF selected.sdf descs.txt=20 > normal " " >=20 > where descs.txt contains all descriptors your interested in in the form= : Burden_modified_eigenvalues:Graph_potentials:4 > Burden_modified_eigenvalues:Graph_potentials:3 > Burden_modified_eigenvalues:Graph_potentials:2 > Burden_modified_eigenvalues:Graph_potentials:1 > Burden_modified_eigenvalues:Graph_potentials:0 > ... >=20 > 2. developer way: > joelib.test.DescriptorCalculation uses a helper class for this kind of=20 > descriptors, which is joelib.desc.util.AtomPropertyDescriptors >=20 > if you use: > setDescriptors2Calculate(new String[]{"Burden_modified_eigenvalues"}); > instead of the default settings you will get only the BCUT entries. >=20 > You can use this class on your own or you can modify the default-jcc=20 > descriptor set in the variable defDescNames > in line -185- in DescriptorCalculation. >=20 > The arrays generated by the AtomPropertyDescriptors class are=20 > automatically mapped to single value descriptors for which you can=20 > calculate the statistic. >=20 > So, with some 'playing around' you should be able to store such results= =20 > directly in a database via JDBC, directly, by avoiding the overhead by=20 > calculating all the other descriptors and the storing in files. >=20 > Kind regards, Joerg >=20 >=20 >>Dear Joerg, >>It's me again. Could you tell me the way to compute only BCUT=20 >>descriptors using the CalculateDescriptors.sh and more generally how=20 >>can I select the descriptors for computation ? Thanks for your help=20 >>Fred >> >>-----Original Message----- >>From: Joerg K. Wegner [mailto:we...@in...] >>Sent: Tuesday, August 24, 2004 12:08 PM >>To: JOELib help >>Cc: Fr=E9d=E9ric Ooms >>Subject: Re: Convert help >> >> >>Dear Fr=E9d=E9ric, >> >>beside the detailed bug report you can also try the extended=20 >>descriptor >>calculation method provided by >> >>calculateDescriptors.sh -- help >> >>I recommend this one anyway. Why ? >>1. The primitive calculation in convert calculates the descriptors by >>using default values (only one atom property). >>2. The extended class >> joelib.test.DescriptorCalculation >> calculates the the descriptors for all available atom properties. >> You can get a list by using: >> sh convert.sh +sad >> >> So this affects especially the BCUT, RDF and GTCI descriptor. >> Furthermore for BCUT and RDF you have additional parameters, like t= he >> smoothing factor for RDF and the k-parameter in BCUT. >> For RDF three different smoothing parameters are used, when using t= he >> extended calculation class. >> >> Then these features can be rescaled using the one dimensional >> Mahalanobis distance (z-score) normalization with mean=3D0 and >> standardDeviation=3D1. >> >>Kind regards, Joerg >> >> >> >>>Dear Fr=E9d=E9ric, >>> >>>please add a bug request with detailed message, system, and example >>>file >>>to the tracking system: >>> >>>http://sourceforge.net/tracker/?group_id=3D39708&atid=3D425969 >>> >>>Kind regards, Joerg >>> >>> >>> >>>>Dear collegues, >>>>I a new JOELIB user as well as a Java newbiess... I am using the=20 >>>>following command line to compute descriptors on a molecule Convert=20 >>>>-h +d test.mol But I get the following error message: >>>>Exception in thread "main" java.lang.NullPointerException at=20 >>>>joelib.Util.JOEPropertyHelper.getProperty.... >>>>Could you help me ? >>>>Regards, >>>>Fred Ooms >>>>--------------------------------------------------------------- >>>>Fr=E9d=E9ric Ooms, Ph.D. >>>>Chemistry Project Manager, Euroscreen S.A. >>>>Rue Adrienne Bolland, 47 >>>>B-6041 Gosselies >>>>Tel. +32 71 348 500 >>>>Fax: +32 71 348 519 >>>> >>>> >>> >>> >> >=20 >=20 --=20 Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-08-24 13:53:23
|
Dear Fr=E9d=E9ric, 1. basic and slow way: 1.1. calculate all descriptors: sh calculateDescriptors.sh +jcc inFile.sdf outFile.sdf 1.2. calculate descriptor statistic to check descriptor occurence. sh statistic.sh -iSDF outFile.sdf this will generate outFile.sdf.statistic outFile.sdf.binning Because BCUT depends on the molecule size, large matrix entries, e.g.=20 Burden_modified_eigenvalues:Graph_potentials:18 (number=3Dinner=20 topological distance) occur not for small molecules. You should only use BCUTS where every molecule has this value, otherwise=20 you should use a 'missing value'-replacing strategy, see also one of my=20 papers for more references: http://www-ra.informatik.uni-tuebingen.de/publikationen/2004/wegner04jcic= sA.html Programs like Dragon hides this problems so they select only a specific=20 number of eigenvalues and uses often 0 for missing values, because the=20 eigenvalues are sorted in decreasing order. But you can not expect that=20 this will give really good models, if the descriptor contains a lot of=20 zeros. 1.3. select descriptors sh descSelection.sh -iSDF outFile.sdf -oSDF selected.sdf descs.txt=20 normal " " where descs.txt contains all descriptors your interested in in the form: Burden_modified_eigenvalues:Graph_potentials:4 Burden_modified_eigenvalues:Graph_potentials:3 Burden_modified_eigenvalues:Graph_potentials:2 Burden_modified_eigenvalues:Graph_potentials:1 Burden_modified_eigenvalues:Graph_potentials:0 ... 2. developer way: joelib.test.DescriptorCalculation uses a helper class for this kind of=20 descriptors, which is joelib.desc.util.AtomPropertyDescriptors if you use: setDescriptors2Calculate(new String[]{"Burden_modified_eigenvalues"}); instead of the default settings you will get only the BCUT entries. You can use this class on your own or you can modify the default-jcc=20 descriptor set in the variable defDescNames in line -185- in DescriptorCalculation. The arrays generated by the AtomPropertyDescriptors class are=20 automatically mapped to single value descriptors for which you can=20 calculate the statistic. So, with some 'playing around' you should be able to store such results=20 directly in a database via JDBC, directly, by avoiding the overhead by=20 calculating all the other descriptors and the storing in files. Kind regards, Joerg > Dear Joerg, > It's me again. Could you tell me the way to compute only BCUT descripto= rs using the CalculateDescriptors.sh and more generally how can I select = the descriptors for computation ? > Thanks for your help > Fred >=20 > -----Original Message----- > From: Joerg K. Wegner [mailto:we...@in...]=20 > Sent: Tuesday, August 24, 2004 12:08 PM > To: JOELib help > Cc: Fr=E9d=E9ric Ooms > Subject: Re: Convert help >=20 >=20 > Dear Fr=E9d=E9ric, >=20 > beside the detailed bug report you can also try the extended descriptor= =20 > calculation method provided by >=20 > calculateDescriptors.sh -- help >=20 > I recommend this one anyway. Why ? > 1. The primitive calculation in convert calculates the descriptors by=20 > using default values (only one atom property). > 2. The extended class > joelib.test.DescriptorCalculation > calculates the the descriptors for all available atom properties. > You can get a list by using: > sh convert.sh +sad >=20 > So this affects especially the BCUT, RDF and GTCI descriptor. > Furthermore for BCUT and RDF you have additional parameters, like t= he > smoothing factor for RDF and the k-parameter in BCUT. > For RDF three different smoothing parameters are used, when using t= he > extended calculation class. >=20 > Then these features can be rescaled using the one dimensional > Mahalanobis distance (z-score) normalization with mean=3D0 and > standardDeviation=3D1. >=20 > Kind regards, Joerg >=20 >=20 >>Dear Fr=E9d=E9ric, >> >>please add a bug request with detailed message, system, and example=20 >>file >>to the tracking system: >> >>http://sourceforge.net/tracker/?group_id=3D39708&atid=3D425969 >> >>Kind regards, Joerg >> >> >>>Dear collegues, >>>I a new JOELIB user as well as a Java newbiess... I am using the >>>following command line to compute descriptors on a molecule >>>Convert -h +d test.mol >>>But I get the following error message: >>>Exception in thread "main" java.lang.NullPointerException at=20 >>>joelib.Util.JOEPropertyHelper.getProperty.... >>>Could you help me ? >>>Regards, >>>Fred Ooms >>>--------------------------------------------------------------- >>>Fr=E9d=E9ric Ooms, Ph.D. >>>Chemistry Project Manager, Euroscreen S.A. >>>Rue Adrienne Bolland, 47 >>>B-6041 Gosselies >>>Tel. +32 71 348 500 >>>Fax: +32 71 348 519 >>> >>> >> >> >=20 >=20 --=20 Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-08-24 10:32:28
|
Dear Fr=E9d=E9ric, > I am working with Windows could you please tell me if a bat file exists= for this procedure ? Windows is not the problem, but bat-files are a problem. Two solutions: 1. For windows-users i strongly recommend to use cygwin http://www.cygwin.com/ Why ? Then you can use unix-shells and also gcc-compiler. Why here for Java ? Because to start the classes all required libraries=20 in lib/*.jar and build should be added to the classpath. Because these settings can be added automatically via shell-scripts i=20 prefer this way. 2. If you are using bat-files you should add all required libraries by=20 hand to this script which is boring and annoying and definitely not=20 up-to-date (so this is a maintenance problem to keep these things=20 up-to-date, my fault). Another possibility would be to unpack all jar files in one single=20 directory and repack them to one single jar. So you have to add only one=20 single jar file to your classpath. Kind regards, Joerg Kurt Wegner > Regards > Fred >=20 > -----Original Message----- > From: Joerg K. Wegner [mailto:we...@in...]=20 > Sent: Tuesday, August 24, 2004 12:08 PM > To: JOELib help > Cc: Fr=E9d=E9ric Ooms > Subject: Re: Convert help >=20 >=20 > Dear Fr=E9d=E9ric, >=20 > beside the detailed bug report you can also try the extended descriptor= =20 > calculation method provided by >=20 > calculateDescriptors.sh -- help >=20 > I recommend this one anyway. Why ? > 1. The primitive calculation in convert calculates the descriptors by=20 > using default values (only one atom property). > 2. The extended class > joelib.test.DescriptorCalculation > calculates the the descriptors for all available atom properties. > You can get a list by using: > sh convert.sh +sad >=20 > So this affects especially the BCUT, RDF and GTCI descriptor. > Furthermore for BCUT and RDF you have additional parameters, like t= he > smoothing factor for RDF and the k-parameter in BCUT. > For RDF three different smoothing parameters are used, when using t= he > extended calculation class. >=20 > Then these features can be rescaled using the one dimensional > Mahalanobis distance (z-score) normalization with mean=3D0 and > standardDeviation=3D1. >=20 > Kind regards, Joerg >=20 >=20 >>Dear Fr=E9d=E9ric, >> >>please add a bug request with detailed message, system, and example=20 >>file >>to the tracking system: >> >>http://sourceforge.net/tracker/?group_id=3D39708&atid=3D425969 >> >>Kind regards, Joerg >> >> >>>Dear collegues, >>>I a new JOELIB user as well as a Java newbiess... I am using the >>>following command line to compute descriptors on a molecule >>>Convert -h +d test.mol >>>But I get the following error message: >>>Exception in thread "main" java.lang.NullPointerException at=20 >>>joelib.Util.JOEPropertyHelper.getProperty.... >>>Could you help me ? >>>Regards, >>>Fred Ooms >>>--------------------------------------------------------------- >>>Fr=E9d=E9ric Ooms, Ph.D. >>>Chemistry Project Manager, Euroscreen S.A. >>>Rue Adrienne Bolland, 47 >>>B-6041 Gosselies >>>Tel. +32 71 348 500 >>>Fax: +32 71 348 519 >>> >>> >> >> >=20 >=20 --=20 Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-08-24 10:05:25
|
Dear Fr=E9d=E9ric,
beside the detailed bug report you can also try the extended descriptor=20
calculation method provided by
calculateDescriptors.sh -- help
I recommend this one anyway. Why ?
1. The primitive calculation in convert calculates the descriptors by=20
using default values (only one atom property).
2. The extended class
joelib.test.DescriptorCalculation
calculates the the descriptors for all available atom properties.
You can get a list by using:
sh convert.sh +sad
So this affects especially the BCUT, RDF and GTCI descriptor.
Furthermore for BCUT and RDF you have additional parameters, like the
smoothing factor for RDF and the k-parameter in BCUT.
For RDF three different smoothing parameters are used, when using the
extended calculation class.
Then these features can be rescaled using the one dimensional
Mahalanobis distance (z-score) normalization with mean=3D0 and
standardDeviation=3D1.
Kind regards, Joerg
> Dear Fr=E9d=E9ric,
>=20
> please add a bug request with detailed message, system, and example fil=
e=20
> to the tracking system:
>=20
> http://sourceforge.net/tracker/?group_id=3D39708&atid=3D425969
>=20
> Kind regards, Joerg
>=20
>> Dear collegues,
>> I a new JOELIB user as well as a Java newbiess... I am using the=20
>> following command line to compute descriptors on a molecule
>> Convert -h +d test.mol
>> But I get the following error message:
>> Exception in thread "main" java.lang.NullPointerException at=20
>> joelib.Util.JOEPropertyHelper.getProperty....
>> Could you help me ?
>> Regards,
>> Fred Ooms
>> ---------------------------------------------------------------
>> Fr=E9d=E9ric Ooms, Ph.D.
>> Chemistry Project Manager, Euroscreen S.A.
>> Rue Adrienne Bolland, 47
>> B-6041 Gosselies
>> Tel. +32 71 348 500
>> Fax: +32 71 348 519
>>
>>
>=20
>=20
--=20
Dipl. Chem. Joerg K. Wegner
Center of Bioinformatics Tuebingen (ZBIT)
Department of Computer Architecture
Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany
Phone: (+49/0) 7071 29 78970
Fax: (+49/0) 7071 29 5091
E-Mail: mailto:we...@in...
WWW: http://www-ra.informatik.uni-tuebingen.de
--
Never mistake motion for action.
(E. Hemingway)
Never mistake action for meaningful action.
(Hugo Kubinyi,2004)
|
|
From: Joerg K. W. <we...@in...> - 2004-08-24 09:39:48
|
Hi Andreas, bug report added to tracking system: http://sourceforge.net/tracker/index.php?func=detail&aid=1015117&group_id=39708&atid=425969 Kind regards, Joerg > Hi all, > > when I try to parse the SMILES 'C2CCC(C1CC1)C2' with JOELib via > > JOESmilesParser.smiToMol(mol, smiles, smiles); > > where 'mol' is a JOEMol object and 'smiles' is a String I keep getting an error: > > =============================================================================== > Exception in thread "main" java.lang.Error: Unresolved compilation problems: > Matrix cannot be resolved or is not a type > The method gMatrix(JOEMol) is undefined for the type GraphPotentials > Matrix cannot be resolved or is not a type > Matrix cannot be resolved or is not a type > The method cMatrix(JOEMol) is undefined for the type GraphPotentials > Matrix cannot be resolved or is not a type > > at joelib.desc.types.GraphPotentials.graphPotentials(GraphPotentials.java:30) > at joelib.molecule.JOEMol.findChiralCenters(JOEMol.java:4261) > at joelib.molecule.JOEAtom.isChiral(JOEAtom.java:609) > at joelib.smiles.JOEMol2Smi.createSmiString(JOEMol2Smi.java:994) > at joelib.util.database.AbstractDatabase.getSMILESHashcode(AbstractDatabase.java:173) > at joelib.molecule.JOEMol.hashCode(JOEMol.java:4905) > at joelib.molecule.JOEMol.reHash(JOEMol.java:5554) > at joelib.molecule.JOEMol.endModify(JOEMol.java:3961) > at joelib.molecule.JOEMol.endModify(JOEMol.java:3857) > at joelib.smiles.JOESmilesParser.parseSmiles(JOESmilesParser.java:1874) > at joelib.smiles.JOESmilesParser.smiToMol(JOESmilesParser.java:1910) > at joelib.smiles.JOESmilesParser.smiToMol(JOESmilesParser.java:124) > at SmilesSmartsViewer.main(SmilesSmartsViewer.java:35) > =============================================================================== > > I have been trying to find the reason and it appears to me that this error occurs especially when two rings are involved like in this example (however, I couldn't find a specific pattern to provoke the error and there are molecules with two rings where it works). > A fellow scientist using this routine told me the error occured in about 10% of the molecules he tried to view. > > Any ideas how to fix this? As our software reaches state 'testing' we should correct this :-) > We are NOT working on the latest JOELib release due to problems with upgrading (see my last posting) but with 2004-06-21 > > Greetings, > Andreas > > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Joelib-help mailing list > Joe...@li... > https://lists.sourceforge.net/lists/listinfo/joelib-help > -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Andreas M. <ma...@in...> - 2004-08-23 10:26:28
|
Hi all, when I try to parse the SMILES 'C2CCC(C1CC1)C2' with JOELib via JOESmilesParser.smiToMol(mol, smiles, smiles); where 'mol' is a JOEMol object and 'smiles' is a String I keep getting an error: =============================================================================== Exception in thread "main" java.lang.Error: Unresolved compilation problems: Matrix cannot be resolved or is not a type The method gMatrix(JOEMol) is undefined for the type GraphPotentials Matrix cannot be resolved or is not a type Matrix cannot be resolved or is not a type The method cMatrix(JOEMol) is undefined for the type GraphPotentials Matrix cannot be resolved or is not a type at joelib.desc.types.GraphPotentials.graphPotentials(GraphPotentials.java:30) at joelib.molecule.JOEMol.findChiralCenters(JOEMol.java:4261) at joelib.molecule.JOEAtom.isChiral(JOEAtom.java:609) at joelib.smiles.JOEMol2Smi.createSmiString(JOEMol2Smi.java:994) at joelib.util.database.AbstractDatabase.getSMILESHashcode(AbstractDatabase.java:173) at joelib.molecule.JOEMol.hashCode(JOEMol.java:4905) at joelib.molecule.JOEMol.reHash(JOEMol.java:5554) at joelib.molecule.JOEMol.endModify(JOEMol.java:3961) at joelib.molecule.JOEMol.endModify(JOEMol.java:3857) at joelib.smiles.JOESmilesParser.parseSmiles(JOESmilesParser.java:1874) at joelib.smiles.JOESmilesParser.smiToMol(JOESmilesParser.java:1910) at joelib.smiles.JOESmilesParser.smiToMol(JOESmilesParser.java:124) at SmilesSmartsViewer.main(SmilesSmartsViewer.java:35) =============================================================================== I have been trying to find the reason and it appears to me that this error occurs especially when two rings are involved like in this example (however, I couldn't find a specific pattern to provoke the error and there are molecules with two rings where it works). A fellow scientist using this routine told me the error occured in about 10% of the molecules he tried to view. Any ideas how to fix this? As our software reaches state 'testing' we should correct this :-) We are NOT working on the latest JOELib release due to problems with upgrading (see my last posting) but with 2004-06-21 Greetings, Andreas |
|
From: Joerg K. W. <we...@in...> - 2004-08-17 07:51:06
|
Hi all, the program for the eCheminfo conference is now Online: http://conferences.metalayer.net/echeminfo/ JOELib is part of the 'Open Source'-session: http://conferences.metalayer.net/echeminfo/design/conference/html/speakerinfoechem.htm Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-08-13 08:34:48
|
Dear Sandeep Vaid, please use for further correspondence the help or developer mailing list. This will avoid answering me questions multiple times. This is done automatically, if you set in joelib/src/joelib.properties joelib.io.types.Smiles.canonical=false to joelib.io.types.Smiles.canonical=true The only problem is that this must be also be set in the joelib.properties file in joelib/build or joelib.jar So if you will compile the sources or build a distribution this will be done automatically. Otherwise you must changes these things on your own or use an additional copy of joelib.properties in the classpath. Kind regards, Joer > Respected Sir, > I want to convert smiles into canonical smiles.Please help me. > > Thanking You, > Sandeep > -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: rich a. <che...@ya...> - 2004-08-13 02:44:01
|
Hello Ola, I can see how the similarities and differences among the half dozen or so Java cheminformatics frameworks/applications might be difficult to pick out (CDK, JChemPaint, JOELib, Octet, Structure, JUMBO, Marvin, soon QSAR, others) . The good news is most of them are open source. I'd like to offer some thoughts on what we're trying to do with Octet (http://octet.sourceforge.net) and Structure (http://structure.sourceforge.net) because I'm most involved with those. Learning a new API is difficult, especially with something as multifaceted as cheminformatics. In part to flatten the learning curve, Octet is designed to deliver the minimal functionality that will be needed in all cheminformatics contexts. This is actually a lot harder than it might sound - the temptation to add just a little bit of extra functionality here and there is very powerful. As a result, Octet's major functionality consists of: (1) The representation of Molecules with any bonding arrangement, from nonclassical carbocations to coordination complexes to inorganics to simple organic compounds is possible. All Molecules are queried using a unified interface that requires no exceptional handling for "wierd" molecules. (2) All model-level objects (Atom, Molecule, etc.) are defined in terms of Java interfaces. The ways that concrete Molecules are implemented can vary drastically, but as long as the interface methods give consistent results, Octet can handle them all. This enables Octet users to fine-tune the Molecule implementation to their particular needs. For example, when dealing with large numbers of Molecules, low memory usage may be a high priority. When working with a limited number of very large Molecules such as proteins, the ability to speedily address and manipulate Atoms and bonding arrangements may be critical. An implementation that works in one case may fail miserably for the other case. So the flexibility to choose is essential for a robust framework. (3) Simplified SMILES, Molfile, and SD file format readers and writers. (4) An API for traversal of Molecules as graph objects. Breadth-first, depth-first, cycle, and isomorphism traversal are all possible via a consistent API. (5) An API for substructure, exact-structure, and query atom queries. (6) Identification of essential Molecule properies such as hydrogen atom count, formal bond order, and electron count. (7) To be implemented in the near future, definition and manipulation of molecular stereochemistry. And that's it for the functionality itself. Of course, this narrow focus leaves many specialized areas untouched, but the features above will be essential for most cheminformatics problems. Recently, support for the use of CDK Molecules within Octet and the use of Octet Molecules within CDK has been developed. This package is called CDKTools. A copy with source code and unit tests can be downloaded here: https://sourceforge.net/project/showfiles.php?group_id=96108 By keeping the API small and simple, we hope to increase the probability that Octet will become a stable framework that is easy to learn, use, and especially extend. Structure extends Octet's capabilities by enabling 2D structure drawing of Molecules. Not much progress has been made on this project recently - due mainly to efforts to move Octet closer to an API freeze and eventual 1.0 release, but it is indeed still alive. The overall approach to Structure is similar to the approach taken with Octet: to deliver the minimal functionality that will be needed in the majority of 2D molecular rendering contexts. 2D coordinate generation falls into that category, and so it is a goal for the project. CDK has has done a wonderful job with 2D structure layout. But there is clearly room for a variety of new approaches in this largely neglected area, especially given the complementary functionality that Octet provides. Regarding JChemPaint and Structure, both are aimed at 2D molecular rendering. However, they address the problem from different perspectives (feel free to correct me if I'm misstating, Egon). JChemPaint is a client-side application/applet that enables both rendering and editing of molecules, and has features that can be used as a library. Structure is solely a framework for 2D Molecule rendering that will provide the functionality on which rendering applications can be built. This may sound like a minor distinction at first, but it results in a very different set of design decisions that need to be made, bugs that need to be fixed, and resource committment. Well, that's a long-winded attempt to try to answer your questions. Let me know if I can give you any further info. best, rich Ola Spjuth <ola...@lc...> wrote: Hello, I am a little confused and don't know how these projects overlap and their licenses. CDK LGPL JOElib GPL Octet LGPL Jmol LGPL Jchempaint GPL Structure LGPL 1) Have I understood the licenses above correctly? On some SF pages (joelib & jchempaint) it says GPL or LGPL. What does that mean? May I choose? 2) How much do CDK and JOElib overlap? I know you can use them together, what are the benefits of this? Descriptors? Will descriptors not be implemented in CDK? 3) What does Octet add to this mix (except that it's LGPL and JOElib is not)? Can it be used with CDK? Overlap? Are the projects competing against each other? 4) What does the Structure project add to all this (except that it's built on Octet and LGPL)? The homepage says they are working on SDG, isn't that already present in CDK? Doesn't JchemPaint do the same thing as Structure? I am posting this question in the CDK, Octet and JOElib mailinglists in order to get more extensive information. Best regards, .../Ola Spjuth -- --- Ola Spjuth, PhD student Dept of Pharmacology & Linnaeus Centre for Bioinformatics Uppsala University, Sweden ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ octet-devel mailing list oct...@li... https://lists.sourceforge.net/lists/listinfo/octet-devel --------------------------------- Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. |
|
From: Joerg K. W. <we...@in...> - 2004-08-12 09:28:20
|
Hi Ola, all things said here are my personal opinion, so please be patient by=20 reading them. > CDK LGPL > JOElib GPL > Octet LGPL > Jmol LGPL > Jchempaint GPL > Structure LGPL >=20 > 1) Have I understood the licenses above correctly? On some SF pages > (joelib & jchempaint) it says GPL or LGPL. What does that mean? May I > choose? Not at all. GPL is harder than LGPL. So in JOELib this means the kernel (this means the chemical expert=20 systems) is GPL and contains some LGPL parts. But you can not change the=20 GPL license. The GPL license comes from the stalled OELib project, so=20 commercial users can buy a OEChem license from EyesOpen, which is the=20 official commercial successor of OELib. > 2) How much do CDK and JOElib overlap? I know you can use them together= , > what are the benefits of this? Descriptors? Will descriptors not be > implemented in CDK? They do not really overlap. Because they have different data structures=20 for molecules. There is a primitive converter class, but not more. So,=20 both have a different focus on what they provide. See documentation and=20 tutorials for details. JOELib contains also LGPL code from Egon (CML) and modified 2D rendering=20 classes from Christoph (no 2D layout, only rendering, no event model)=20 which allows also to show SMARTS matchings and to export images and PDF. Descriptors? Depends on the kind of the descriptors i would say, but=20 JOELib is here much more advanced (but i might be not objective here). > 3) What does Octet add to this mix (except that it's LGPL and JOElib is > not)? Can it be used with CDK? Overlap? Are the projects competing > against each other? No competition is the last thing we are interested in, because we are=20 too less developers to be really competitive. We are trying to combine=20 the different data structures in a general way in the octet project. But=20 this is still under discussion and far away from a concrete implementatio= n. So, on long terms this might provide a common interface. Hopefully this will faciliate the usage of a chemoinformatics tools and=20 faciliate the project maintenance, we will see ... > 4) What does the Structure project add to all this (except that it's > built on Octet and LGPL)? The homepage says they are working on SDG, > isn't that already present in CDK? Doesn't JchemPaint do the same thing > as Structure? Rich, is this project stalled or in progress ? > I am posting this question in the CDK, Octet and JOElib mailinglists in > order to get more extensive information. Crossposting causes always many e-mails for users subscribed to all=20 users. If you bear such things always in mind, this is o.k. CU, J=F6rg --=20 Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Ola S. <ola...@lc...> - 2004-08-12 08:53:21
|
Hello, I am a little confused and don't know how these projects overlap and their licenses. CDK LGPL JOElib GPL Octet LGPL Jmol LGPL Jchempaint GPL Structure LGPL 1) Have I understood the licenses above correctly? On some SF pages (joelib & jchempaint) it says GPL or LGPL. What does that mean? May I choose? 2) How much do CDK and JOElib overlap? I know you can use them together, what are the benefits of this? Descriptors? Will descriptors not be implemented in CDK? 3) What does Octet add to this mix (except that it's LGPL and JOElib is not)? Can it be used with CDK? Overlap? Are the projects competing against each other? 4) What does the Structure project add to all this (except that it's built on Octet and LGPL)? The homepage says they are working on SDG, isn't that already present in CDK? Doesn't JchemPaint do the same thing as Structure? I am posting this question in the CDK, Octet and JOElib mailinglists in order to get more extensive information. Best regards, .../Ola Spjuth -- --- Ola Spjuth, PhD student Dept of Pharmacology & Linnaeus Centre for Bioinformatics Uppsala University, Sweden |
|
From: Andreas M. <ma...@in...> - 2004-08-03 14:55:03
|
Hi,
I figured out solutions to both problems:
security error:
+++++++++++++++
in the file $JAVA_HOME/jre/lib/security/java.policy make changes like this:
OLD:
grant codeBase "file:${java.home}/lib/ext/*" {
permission java.security.AllPermission;
};
NEW:
grant {
permission java.security.AllPermission;
};
to allow all JAVA-code actions like 'System.exit()' (especially the one in your developer directory).
chirality and cis-trans-iso support:
++++++++++++++++++++++++++++++++++++
Install the jdom library from jdom.org
Greetings
Andi
|
|
From: Andreas M. <ma...@in...> - 2004-08-02 13:15:42
|
Hi, we experience problems using JOELib on molecules whose SMILES contains '@'-signs (to denote chirality) or '\'-signs (to denote cis-trans-isometry). That is, they won't display in our JOELib based viewer. Doesn't JOELib support these? Greets, Andi |
|
From: Andreas M. <ma...@in...> - 2004-08-02 13:12:22
|
Hi,
I keep getting an error with the latest version of joelib:
I try to run an applet with
$> appletviewer SmilesSmartsViewerApplet.html
and this happens:
+++++++++++++++++++++++++++++++++++++++++
log4j:WARN No appenders could be found for logger (wsi.ra.PropertyHolder).
log4j:WARN Please initialize the log4j system properly.
java.lang.ExceptionInInitializerError
at joelib.smarts.JOESmartsPattern.<init>(JOESmartsPattern.java:129)
at SmilesSmartsViewerApplet.init(SmilesSmartsViewerApplet.java:16)
at sun.applet.AppletPanel.run(AppletPanel.java:353)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission exitVM)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at java.lang.SecurityManager.checkExit(SecurityManager.java:736)
at java.lang.Runtime.exit(Runtime.java:88)
at java.lang.System.exit(System.java:715)
at wsi.ra.tool.PropertyHolder.instance(PropertyHolder.java:281)
at wsi.ra.tool.PropertyHolder.instance(PropertyHolder.java:258)
at joelib.smarts.ParseSmart.<clinit>(ParseSmart.java:122)
... 4 more
+++++++++++++++++++++++++++++++++++++++++
The same in JAVA-enabled browsers. However, Eclipse runs the very same code without any errors.
I didn't change anything in my program, just exchanged JOELIB and CDK against new versions.
Any ideas?
Greets,
Andi
|
|
From: Joerg K. W. <we...@in...> - 2004-07-29 10:49:24
|
Hi Dave, first ... i'm going today into holiday until the end of next week. Yes, this was a bug in the detection and: UP is '/' DOWN is '\\' CIS is C/C=C\C TRANS is C/C=C/C I've created a (non-planned) bug fix release. The previous changes caused also SMILES export and i hope this is now correct. Please let me know if not not and send a bug report via the bug tracking list. I've additionally added unspecific up/down bond matching using '\\?' and '/?'. Please note that you need C/?C=C/?C if you plan to match plain butene, also. Download: https://sourceforge.net/projects/joelib/ Kind regards, Joerg > First, thanks for the new release. > > I've been experimenting with TestSmarts.java, using trans_butene.mol and > cis_butene.mol in .../build/resources/smartsEvaluation/. It seems to be > doing the exact opposite of what I'd expect: > > trans_butene.mol(C\C=C\C) > debugging output says "C\C=C/C trans-butene" > TestSmarts trans_butene.mol C\\C=C/C matches > trans_butene.mol C/C=C\\C matches > trans_butene.mol C\\C=C\\C doesn't match > trans_butene.mol C/C=C/C doesn't match > cis_butene.mol(C\C=C/C) > debugging output says "C\C=C\C cis-butene" > TestSmarts cis_butene.mol C\\C=C/C doesn't match > cis_butene.mol C/C=C\\C doesn't match > cis_butene.mol C\\C=C\\C matches > cis_butene.mol C/C=C/C doesn't match * > > * There's a note about this in evaluation.txt > > Notice the debugging output from the println on line 146 of TestSmarts.java. > -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Dave R. <roe...@tc...> - 2004-07-29 02:48:23
|
First, thanks for the new release.
I've been experimenting with TestSmarts.java, using trans_butene.mol and
cis_butene.mol in .../build/resources/smartsEvaluation/. It seems to be
doing the exact opposite of what I'd expect:
trans_butene.mol(C\C=C\C)
debugging output says "C\C=C/C trans-butene"
TestSmarts trans_butene.mol C\\C=C/C matches
trans_butene.mol C/C=C\\C matches
trans_butene.mol C\\C=C\\C doesn't match
trans_butene.mol C/C=C/C doesn't match
cis_butene.mol(C\C=C/C)
debugging output says "C\C=C\C cis-butene"
TestSmarts cis_butene.mol C\\C=C/C doesn't match
cis_butene.mol C/C=C\\C doesn't match
cis_butene.mol C\\C=C\\C matches
cis_butene.mol C/C=C/C doesn't match *
* There's a note about this in evaluation.txt
Notice the debugging output from the println on line 146 of TestSmarts.java.
--
Dave Roe roe...@tc...
|
|
From: Joerg K. W. <we...@in...> - 2004-07-27 15:51:31
|
Hi Rich,
I've changed the subject to being more precisely.
I agree that things are getting complex, but primitive native
numeric/nominal descriptors are only a really small subset of all
possible codings for molecular structures (descriptor results).
descriptor (parameters, molecule): algorithm to get values
descriptor result: storing object for the abstract molecule
numeric,nominal value, binary nominal value,
atom-pair, mcs, ...
query (parameters): a search method getting a list of valid matchings
e.g. SMARTS, AP, shape, whatever, ...
metric (parameters, descRes1, descRes2): Getting similarity for two
possibly codings
> But one thing that is not clear to me is how a generic Metric (or Comparator) does its job (without violating encapsulation) of comparing two Descriptor calculations given that the way in which each Descriptor represents itself is unique. For example, a Tanamoto comparison of two fingerprints will be done one way, but a Tanamoto comparison of two TPSA's will be done very differently. A Euclidian distance comparison of Topological Torsion is straightforward, but the same comparison of clogP - that's done very differently, I imagine.
Generic would not be the correct term.
The basic problem we always have is that 'similarity' can and definitely
should not be separated from the metric, because a metric can only
interpret the features given.
I've tried to find a structure for my private literature and i've now
the opinion that coding and similarity are two sides of a coin.
So, we can have different images on one of the two sides, but we can not
split the coin.
So, eventually every descriptorResult should have something like:
List=descriptorResult.getPossibleMetrics();
And i've also the opinion that we should be really general here, because
most model building algorithms (classification, regression, clustering)
need most often only a kind of similarity and a meanValue for a set of
molecules.
And the primitive euclidian distance of descriptor (sub)sets is only the
plain data mining approach with loosing all topologial information
(inverse QSAR problem).
> And then there's the problem that a generic Metric will need a much wider Descriptor interface to do a comparison than a generic DescriptorResult or Descriptor will have.
Hmm, i think the result holds the: coding
and the metric addresses: similarity on coding
> How does JOELib handle these issues?
Not good and really diverse.
For general descriptor results i've recently introduced:
joelib.math.similarity.DistanceMetric
For basic values (numeric or nominal or binary nominal), furthermore
there are some hot topics working directly on molecular structures. I
will not discuss these things on the public mailing list, but i'm
definitely willingly to cooperate here, if the plan is to write a paper
using one of the new methods. For all methods we have the atom labelling
(set) problem !
EUCLIDIAN, TANIMOTO:
joelib.util.ComparisonHelper
the euclidian or tanimoto metric is chosen from the kind of descriptor
given to
setComparisonDescriptor(String)
setComparisonDescriptor(String[])
ATOM-PAIR (also unpublished work of Nikolas Fechner available, still in
development)
joelib.desc.types.atompair.BasicAPDistanceMetric
MCS(not public, still in development, paper submitted, eventually i will
publish after the paper was accepted, but i'm not sure if i'm willingly
to share the implementation advantages so early)
Really weird, but i will prefer the abstractest object oriented way you
can provide.
In fact two results (coding) and metric based on these results.
But there are tons of ways you can code (parameters for MCS generation)
the MCS and you can apply the metric (parameters for metric)
> It almost seems like the "Descriptor" category itself is overly general and needs to be broken down further. Otherwise any Descriptor framework will have to know too much about particular Descriptor implementations with the result being a decidedly non-object-oriented framework that is difficult to extend and maintain. How can we address this?
In JOElib every descriptor knows it's result, so if you call
result=descriptor.calculate(molecule)
you will get the correct result. Because this is done by using
Java-Reflection this is not the most efficient way, but if we use
result=descriptor.calculate(molecule, result) this will be efficient.
Hence, standard users will have to pay a runtime-penalty, because object
generation in Java is expensive (see also joelib.desc.ResultFactory).
I suggest that every result should know possible metrics.
I've also introduced a joelib.desc.DescriptorInfo object
Additionally there exists the DescDescription object which holds
informations for each descriptor. If you will try:
joelib/ant> ant JOELibTestGUI
And you will switch to Info-->Descriptors Panel all informations are
generated and loaded on the fly by using:
111. DescriptorFactory (get all descriptors JOELib can calculate, so we
know the details for them, BTW unavailable documentation will cause
annoying warnings, so developers are forced to provide from the
beginning documentation files)
222. Get descriptor infos for each descriptor
333. Load single HTML documentation (generated also from DocBook-XML)
for each descriptor
444. show informations.
Kind regards, Joerg
>
> rich
>
> "Joerg K. Wegner" <we...@in...> wrote:
> Hi again,
>
> we should for performace issues not use (as in JOElib):
> molecule.calculate("XYZ")
>
> we should use:
> keyXYZ=KeyFactory.getKey("XYZ");
>
> // and use internal caching for this descriptor
> molecule.calculate(keyXYZ);
>
> Kind regards, Joerg
>
>
>>Hi Rich,
>>
>>
>>>* Molecule implements AtomGraph. In the near future, BondingSystem
>>>should also implement AtomGraph to enable traversal/query with the
>>>same tools used for Molecules (any objections to this?)
>>
>>Good.
>>
>>
>>>* Traversers traverse the graph structure of any AtomGraph. Traversers
>>>are low-level components that are helpful for building higher-level
>>>functionality. Currently two types of Traverser are available:
>>>DepthFirstTraverser and CycleTraverser. Both use a system of Handlers
>>>and Controllers - Handlers for handling events generated at various
>>>stages of a traversal algorithm and Controllers for exercising limited
>>>control over the algorithm itself. This system borrows from SAX's
>>>ContentHandler idea. HanserCycleTraverser is an implementation of
>>>CycleTraverser that uses Hanser's algorithm for finding the set of all
>>>cycles of an AtomGraph using collapsing Path-Graphs.
>>
>>CycleTraverser should use an interface, so that we can switch the
>>traverser.
>>If nothing is said a default traverser should be used.
>>The traverser should also have an ID and version number analogue to
>>descriptors.
>>
>>
>>
>>>* MoleculeComparator compares two AtomGraphs for isomorphism, but
>>>without comparing atom/bonding properties. UllmanComparator implements
>>>MoleculeComparator by using Ullman's subgraph isomorphism algorithm.
>>>Like Traverser, MoleculeComparator uses a system of Handlers and
>>>Controllers for fine-grained control. It should be possible to use
>>>this sytem to create additional isomorphism algorithms implementing
>>>MoleculeComparator.
>>
>>Isn't this only a formulation problem ?
>>Can't we use a boolean method compareNode(LabelSet) which uses a set of
>>labels to check isomorphism ?
>>
>>
>>>* QueryBuilder enables clients to build a molecular query using the
>>>same process that is used for building a Molecule with
>>>MoleculeBuilder. In fact, QueryBuilder extends MoleculeBuilder and can
>>>be used in many contexts calling for a MoleculeBuilder. QueryBuilder
>>>is designed for building queries that are based on a template molecule
>>>with constraints placed on individual Atoms with AtomQuery.
>>
>>Can 'pharmacophores' treated also with this approach. So are combined
>>features, e.g. carbon acid group combined to a single feature and a
>>distance to all other features allowed ?
>>
>>
>>
>>>* SmartsQueryFactory is in the early stages, but is intended to
>>>simplify the process of using QueryBuilder by enabling clients to use
>>>SMARTS Atomic Primitive strings as keys to obtain a fully functional
>>>AtomQuery. Although this isn't exactly a SMARTS parser, it isn't that
>>>far from being one given Octet's SmilesReader. Currenly only the
>>>wildcard Atomic Primitive ("*") is supported, but other should be
>>>appearing soon. The approach here has some elements in common with
>>>that of CDK's growing SMARTS support, but there are also some
>>>interesting differences.
>>
>>Same as above, so atom based (not feature based) compareNode(LabelSet)
>>method, where the LabelSet is what i would call the chemical kernel atom
>>labelling set.
>>
>>
>>>Looking a little further down the road for QSAR, what are people's
>>>thoughts on a framework for molecular descriptors? Of course, there
>>>hundreds of descriptors, and of course we all have our ideas on what a
>>>particular descriptor means or doesn't mean. What I'm actually
>>>wondering about is what a descriptor facility in QSAR would look and
>>>feel like. I've been looking at JOELib's descriptor framework, which
>>>has some reasonable concepts. From what I can tell, there are two
>>>basic kinds of descriptor: a "holistic" descriptor that is a single
>>>value (i.e. TPSA) and which is primitive-like, and everything else,
>>>which tends to be higher-resolution in nature (i.e. Topological
>>>Torsion) and more object-like. Are there any other ideas?
>>
>>With respect to query i would prefer the object approach, so we can use:
>>result=molecule.calculate("XYZ")
>>or as in JOELib
>>result1=calculator.calculate(mol1,"XYZ", Properties)
>>result2=calculator.calculate(mol2,"XYZ", Properties)
>>
>>for matching or similarity we can then use
>>// inherited from Comparator in Java API
>>// applicable for euclidian, tanimoto, atom-pairs
>>similarity=metricThatILike(result1,result2, Properties);
>>
>>For simple single value descriptors it would be also interesting to have:
>>similarity=metricThatILike(ResultSet1,ResultSet2, Properties);
>>Also with pharmacophore outlook or multiple graph isomorphism and not
>>only pair-wise matching.
>>
>>So a query is from my standpoint a kind of similarity-metric which can
>>only return 0 and 1. Sometimes, as in SMARTS matching we are only
>>interested in subgraph isomorphism.
>>result1=calculator.calculate(mol1,"XYZ", LabelSet)
>>result2=calculator.calculate(mol2,"XYZ", LabelSet)
>>// only applicable for this specific calculator
>>// can be used for maximum common substructure search (MCS)
>>matchings=matchingsThatILike(result1,result2, Properties);
>>
>>So, for SMARTS matching we need also:
>>matchings=matchingsThatILike(query1,result2, Properties);
>>
>>For pharmacophores 2D/3D/Shape we can also use this appraoch, because
>>the representation for the similarity/matching is the relevant point.
>>matchings=matchingsThatILike(query1,result2, Properties);
>>or
>>similarity=metricThatILike(result1,result2, Properties);
>>
>>Kind regards, Joerg
>>
>>
>
>
>
--
Dipl. Chem. Joerg K. Wegner
Center of Bioinformatics Tuebingen (ZBIT)
Department of Computer Architecture
Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany
Phone: (+49/0) 7071 29 78970
Fax: (+49/0) 7071 29 5091
E-Mail: mailto:we...@in...
WWW: http://www-ra.informatik.uni-tuebingen.de
--
Never mistake motion for action.
(E. Hemingway)
Never mistake action for meaningful action.
(Hugo Kubinyi,2004)
|
|
From: Joerg K. W. <we...@in...> - 2004-07-26 07:45:23
|
Hi Egon, sorry for cross-posting, but this is interesting for all java-project-admins. good old ANT, i've attached the build file, no it's not in the CVS. I've simply used all old sf-source-code-releases to get an objective PMD measure. Unfortunately setting properties seems only to work sometimes ? I don't get it. So, i've started the script for each PMD metric. You can download the required libraries at: http://sourceforge.net/project/showfiles.php?group_id=39708&package_id=108845 Kind regards, Joerg > On Monday 26 July 2004 00:05, Joerg K. Wegner wrote: > >>- Extensive PMD, JavaNCSS offline statistics, so on long term runs there >>are some non-functioanlity things to do ... just for improving the >>design and becoming more user friendly :-) >>http://www-ra.informatik.uni-tuebingen.de/software/joelib/statistics.html > > > That's a nice page... how did you create those in-time statistics? > Are the scripts in JOELib CVS? > > Egon > -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Egon W. <eg...@us...> - 2004-07-26 06:49:45
|
On Monday 26 July 2004 00:05, Joerg K. Wegner wrote: > - Extensive PMD, JavaNCSS offline statistics, so on long term runs there > are some non-functioanlity things to do ... just for improving the > design and becoming more user friendly :-) > http://www-ra.informatik.uni-tuebingen.de/software/joelib/statistics.html That's a nice page... how did you create those in-time statistics? Are the scripts in JOELib CVS? Egon -- eg...@sc... GPG: 1024D/D6336BA6 |
10 messages has been excluded from this view by a project administrator.
