cdk-devel — Developers forum for discussion on the Chemistry Development Kit

Re: [Cdk-devel] Question: Can CDK do ***? (Was: Update: IUPAC name generator)

[Christoph S. <ste...@ic...>]

Egon Willighagen wrote:

> Can CDK:
> 1. ... saturate the molecule with hydrogen? How? (And remove them?)
> 2. ... draw 2D images with colored atoms?

I'm stunned by this progress :-)

To answer your questions:

1. I do not remeber any method for adding hydrogens to saturate a 
molecule. There is, however, as method "saturate" in 
org.openscience.cdk.tools.SaturationChecker, which adjusts bond orders 
in order to saturate a molecule. This can be used in case on does not 
have bond orders but only connectivities (pdb file, or output of some 
structure generators)
This method should be copied to saturateWithHydrogens() and adjusted to 
add Hydrogens instead of increasing bondorders.

2. Atoms can be colored by using the ColorHashtable in the Renderer2DModel.
This allows you to assign arbitrary colors to arbitrary atoms by 
throwing the atom object to be colored into the hashtable as a key 
together with the java.awt.Color to be used for coloring this atom.

Cheers,

Chris

-- 
Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf)
MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 
Jena, Germany
Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202

What is man but that lofty spirit - that sense of enterprise.
... Kirk, "I, Mudd," stardate 4513.3..

[Cdk-devel] Question: Can CDK do ***? (Was: Update: IUPAC name generator)

[Egon W. <eg...@sc...>]

On Wednesday 11 September 2002 22:00, Egon Willighagen wrote:
> I've had a few hours to do further work on the IUPAC name generator...
> The design seems to be working:
>
> I've (partly) implemented two rules in Section A (1.1 and 2.1), and the
> current version can name these compounds in two languages (English
> and Dutch):
>
> methane, ethane, up to, decane (rule 1.1)
>
> and
>
> isobutane (rule 2.1)

Added isopentane and isohexane.

> Before I will do a first release I want to implement naming of Fragment
> class types, aka radicals... like ethyl, etc...

Done. It will now properly name methyl - decyl... It acutually already is a 
recursive algorithm... that is, it can now handle structures that need to be
split in smaller parts to be named. To be specific, it can name branched
alkanes now, but only the fragments, the output is not correctly ordered 
yet ;) Neither does it add localization numbers defining how the fragments
are connected yet...

> The output of the program is the IUPAC name (yes, of course ;), but also
> the applied rules... the latter is of much interest of you need to know
> which were applied (and in which order)... future version will even be able
> to map fragments of the named molecule with parts of the name, and the
> applicable rule...

I've been rewriting the data structures for the IUPAC name result. This is 
almost done. The software *will* include a mechanism that shows you which
part of the molecule resulted in which IUPAC name part (which I am very happy 
about)

But, I have two questions:

Can CDK:
1. ... saturate the molecule with hydrogen? How? (And remove them?)
2. ... draw 2D images with colored atoms?

The latter I want to use to color each IUPAC name part with a different color.
(Preferably, I want to highlight only one part, which you could select with 
the mouse... but I must start somewhere ;)

Egon

[Cdk-devel] Re: [Cdk-commits] CVS: cdk/src/org/openscience/cdk/smiles SmilesGenerator.java,1.9,1.10

[E.L. W. <eg...@sc...>]

On Friday 13 September 2002 17:05, Stefan Kuhn wrote:
> excuse my German, it's a personal comment and more or less a bug. I hope to
> remove the comment (and the underlying) problem soon. 

Please don't !

The CDK source code already contains too little documentation... and 
documentation should not be limited to some general overview... Within
algorithm (aka step by step) documentation is very, *very* valuable....

> Also I wanted to
> avoid that everybody sees that my code is not perfect :-)

Yes, that is my fear too often ;)

Egon

PS. I hope you don't mind me cc-ing this to cdk-devel@

[Cdk-devel] Update: IUPAC name generator

[Egon W. <eg...@sc...>]

Hi all,

I've had a few hours to do further work on the IUPAC name generator...
The design seems to be working:

I've (partly) implemented two rules in Section A (1.1 and 2.1), and the
current version can name these compounds in two languages (English
and Dutch):

methane, ethane, up to, decane (rule 1.1)

and

isobutane (rule 2.1)

Before I will do a first release I want to implement naming of Fragment
class types, aka radicals... like ethyl, etc...

The output of the program is the IUPAC name (yes, of course ;), but also
the applied rules... the latter is of much interest of you need to know which
were applied (and in which order)... future version will even be able to map 
fragments of the named molecule with parts of the name, and the applicable 
rule...

Egon

Re: [Cdk-devel] Cloning?

[E.L. W. <eg...@sc...>]

On Tuesday 10 September 2002 10:06, E.L. Willighagen wrote:
> The Crystal class contains a clone() method, but is does not work
> properly. Can anyone give me some tips?

Never mind... found the problem. It was interfering with another method
which used clone() but that had a bug...

Egon

[Cdk-devel] Cloning?

[E.L. W. <eg...@sc...>]

Hi all,

The Crystal class contains a clone() method, but is does not work
properly. Can anyone give me some tips?

The code in CVS looks like:

    public Object clone() {
        Crystal o = null;
        try {
            o = (Crystal)super.clone();
        } catch (Exception e) {
            e.printStackTrace(System.err);
        }
        o.setSpaceGroup(this.getSpaceGroup());
        o.setA(this.ax, this.ay, this.az);
        o.setB(this.bx, this.by, this.bz);
        o.setC(this.cx, this.cy, this.cz);
        return o;
    }

And I've also used:

    public Object clone() {
        Crystal o = new Crystal();
        o.setSpaceGroup(this.getSpaceGroup());
        o.setA(this.ax, this.ay, this.az);
        o.setB(this.bx, this.by, this.bz);
        o.setC(this.cx, this.cy, this.cz);
        try {
            o.add((AtomContainer)super.clone());
        } catch (Exception e) {
            e.printStackTrace(System.err);
        }
        return o;
    }


But both give this error:

org.openscience.cdk.exception.NoSuchAtomException: No such Atom
        at 
org.openscience.cdk.AtomContainer.getAtomNumber(AtomContainer.java:274)
        at org.openscience.cdk.AtomContainer.clone(AtomContainer.java:1065)
        at org.openscience.cdk.Crystal.clone(Crystal.java:255)
        at org.openscience.cdk.Crystal.getP1Cell(Crystal.java:191)
        at com.egonw.crystal.SelectAtoms.main(SelectAtoms.java:133)

The problem seems to be in the clone() method of AtomContainer...
Is my code incorrect? Or is there a bug in AtomContainer.clone()?

Egon

Re: [Cdk-devel] CFV: CDK RFC #3 "Tests in org.openscience.cdk.test Use Same Directory Structure as Tested Classes"

[Edgar L. <ed...@up...>]

> START VOTING BALLOT
> =============================================================
> 
>  Name:
>  Email:
>  PGP/GPG key:
> 
>  I vote
> 
>   [X] YES
>   [ ] NO
> 
>  on the acceptance of RFC #3 posted on 30 July 2002 with the
>  title "Tests in org.openscience.cdk.test Use Same Directory Structure as
>  Tested Classes".  The content of this RFC can be
>  found at http://cdk.sourceforge.net/rfc3.html.
> 
> =============================================================
> END VOTING BALLOT

-- 
Edgar Luttmann

University of Paderborn, Germany
Department of organic chemistry
                                                office: J6.302
Warburger Str. 100                              phone:  (+49) 5251
60-2498
33098 Paderborn                                 eMail:  ed...@up...

Re: [Cdk-devel] Fwd: CFV: CDK RFC #4 "

[Edgar L. <ed...@up...>]

>  START VOTING BALLOT
>  =============================================================
> 
>   Name:
>   Email:
>   PGP/GPG key:
> 
>   I vote
> 
>   [X] YES
>   [ ] NO
> 
>   on the acceptance of RFC #4 first posted on 14 August  2002 with the 
>   title "Core classes must not check method parameters".  The content of 
>   this RFC can be   found at http://cdk.sourceforge.net/rfc4.html.
> 
>  =============================================================
>  END VOTING BALLOT

-- 
Edgar Luttmann

University of Paderborn, Germany
Department of organic chemistry
                                                office: J6.302
Warburger Str. 100                              phone:  (+49) 5251
60-2498
33098 Paderborn                                 eMail:  ed...@up...

Re: [Cdk-devel] Fwd: CFV: CDK RFC #4 "

[Egon W. <eg...@sc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>  START VOTING BALLOT
>  =============================================================
>
>   Name: Egon Willighagen
>   Email: eg...@sc...
>   PGP/GPG key: 0xD6336BA6
>
>   I vote
>
>   [X] YES
>   [ ] NO
>
>   on the acceptance of RFC #4 first posted on 14 August  2002 with the
>   title "Core classes must not check method parameters".  The content of
>   this RFC can be   found at http://cdk.sourceforge.net/rfc4.html.
>
>  =============================================================
>  END VOTING BALLOT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9ef5fd9R8I9Yza6YRAhM8AJ0dw5XkX98Ivecf6z6z9Ov+02CQfgCgxGCc
WyKwu032x9xkg0n9iqFtyiY=
=zDe5
-----END PGP SIGNATURE-----

Re: [Cdk-devel] CFV: CDK RFC #3 "Tests in org.openscience.cdk.test Use Same Directory Structure as Tested Classes"

[Egon W. <eg...@sc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> START VOTING BALLOT
> =============================================================
>
>  Name: Egon Willighagen
>  Email: eg...@sc...
>  PGP/GPG key: 0xD6336BA6
>
>  I vote
>
>   [X] YES
>   [ ] NO
>
>  on the acceptance of RFC #3 posted on 30 July 2002 with the
>  title "Tests in org.openscience.cdk.test Use Same Directory Structure as
>  Tested Classes".  The content of this RFC can be
>  found at http://cdk.sourceforge.net/rfc3.html.
>
> =============================================================
> END VOTING BALLOT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9ef4ud9R8I9Yza6YRAsdtAJ93D/2Xe58zFDXiQb+yB3qrtMCZOQCfU5tU
Urooh7RC2ENzhsq/pD7d81Y=
=XjDh
-----END PGP SIGNATURE-----

Re: [Cdk-devel] CFV: CDK RFC #3 "Tests in org.openscience.cdk.test Use Same Directory Structure as Tested Classes"

[Christoph S. <ste...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----

 > START VOTING BALLOT
 > =============================================================
 >
 >  Name:
 >  Email:
 >  PGP/GPG key:
 >
 >  I vote
 >
 >   [x] YES
 >   [ ] NO
 >
 >  on the acceptance of RFC #3 posted on 30 July 2002 with the
 >  title "Tests in org.openscience.cdk.test Use Same Directory
 > Structure as
 >  Tested Classes".  The content of this RFC can be
 >  found at http://cdk.sourceforge.net/rfc3.html.
 >
 > =============================================================
 > END VOTING BALLOT


- --
Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf)
MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745
Jena, Germany
Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202

What is man but that lofty spirit - that sense of enterprise.
... Kirk, "I, Mudd," stardate 4513.3..

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQCVAwUBPXWtTVBubKagaZqZAQGhYAP+OzkvZ/Qx4n7LN1zj2KjSuDjIWn8/YAEq
bOj0QF1m8OQKdj1Di7TzZfu8H7I09pnPLJst5ZCntgrAdapmx0AJJIXosbJqFQ8O
S7b6DXMXze2+voTWG2ol725cxkwMc0DZn/9auNThReLdy15rwz6a8zyR21T3gNWf
gYNVmohlakM=
=eF3S
-----END PGP SIGNATURE-----

Re: [Cdk-devel] Fwd: CFV: CDK RFC #4 "

[Christoph S. <ste...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----

 >  START VOTING BALLOT
 >  =============================================================
 >
 >   Name:
 >   Email:
 >   PGP/GPG key:
 >
 >   I vote
 >
 >   [x] YES
 >   [ ] NO
 >
 >   on the acceptance of RFC #4 first posted on 14 August  2002 with
 > the
 >   title "Core classes must not check method parameters".  The
 > content of
 >   this RFC can be   found at http://cdk.sourceforge.net/rfc4.html.
 >
 >  =============================================================
 >  END VOTING BALLOT


- --
Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf)
MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745
Jena, Germany
Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202

What is man but that lofty spirit - that sense of enterprise.
... Kirk, "I, Mudd," stardate 4513.3..

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQCVAwUBPXWsG1BubKagaZqZAQHL9wP/XuS4QZwlL4quvN8Owa8DJrcBgSRyrvAf
xGAEjc8C0uqarxVUsffrW8mOGgD4Yoe+DCcxbHCqDEzlLRXxecsm0PsbA1O2h7O8
ev8j2+saUFZaae0JNxjhN8eNs3aEt2VX4wFetft3KC2XEy/BCmfSGHTQYC64RhMs
PDBab4F1BHo=
=8KGN
-----END PGP SIGNATURE-----

Re: [Cdk-devel] CFV: CDK RFC #3 "Tests in org.openscience.cdk.test Use Same Directory Structure as Tested Classes"

[E.L. W. <eg...@sc...>]

Oops.... that was a mistake... the ballot sent is not valid! The
date does not match the actual data of proposal. It should
be 30 July 2002 instead of 30 August 2002.

NOTE THAT ALL OTHER DATES ARE VALID AND VOTING
ENDS AT:

18 September 2002 00:00 GMT

Below is a valid voting ballot.

START VOTING BALLOT
=============================================================

 Name:
 Email:
 PGP/GPG key:

 I vote

  [ ] YES
  [ ] NO

 on the acceptance of RFC #3 posted on 30 July 2002 with the
 title "Tests in org.openscience.cdk.test Use Same Directory Structure as
 Tested Classes".  The content of this RFC can be
 found at http://cdk.sourceforge.net/rfc3.html.

=============================================================
END VOTING BALLOT

The original message was:

On Tuesday 03 September 2002 18:09, E.L. Willighagen wrote:
> Hi all,
>
>   time for some more Call For Votes (CFVs).
>
>   This message closes the discussion on CDK RFC #3 first posted on
>   30 August  2002 with the title "Tests in org.openscience.cdk.test Use
> Same Directory Structure as Tested Classes". Any further proposal about the
> topics in RFC #3 need to be posted as a new RFC.
>
>   Any developer and user of CDK is allowed and encouraged to vote.
>   Please send your completed voting ballot (name, email address, and
>   optionally you PGP/GPG key) to cdk...@li... before:
>
>     18 September 2002 00:00 GMT
>
>   Votes sent to other email addresses are invalid. Posting of multiple
> votes also leads to invalid votes. Preferably your vote (see ballot below)
> is signed with your PGP/GPG key.
>
>   More information about CDK's RFC can be found at
>   http://cdk.sourceforge.net/rfc.html, but feel free to ask questions
>   at the developers mailling list: cdk...@li....
>
>   The results of the votes will be sent to the developers mailling
>   list after 17 September 2002.
>
>   kind regards,
>
>   Egon Willighagen
>
>  START VOTING BALLOT
>  =============================================================
>
>   Name:
>   Email:
>   PGP/GPG key:
>
>   I vote
>
>   [ ] YES
>   [ ] NO
>
>   on the acceptance of RFC #3 posted on 30 August 2002 with the
>   title "Tests in org.openscience.cdk.test Use Same Directory Structure as
>   Tested Classes".  The content of this RFC can be
>   found at http://cdk.sourceforge.net/rfc3.html.
>
>  =============================================================
>  END VOTING BALLOT
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Cdk-devel mailing list
> Cdk...@li...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel

[Cdk-devel] Fwd: CFV: CDK RFC #4 "

[E.L. W. <eg...@sc...>]

Hi all,

  time for some more Call For Votes (CFVs).

  This message closes the discussion on CDK RFC #4 first posted on
  14 August  2002 with the title "Core classes must not check method
   parameters". Any further proposal about the topics in RFC #4 need 
   to be posted as a new RFC.

  Any developer and user of CDK is allowed and encouraged to vote.
  Please send your completed voting ballot (name, email address, and
  optionally you PGP/GPG key) to cdk...@li... before:

    18 September 2002 00:00 GMT

  Votes sent to other email addresses are invalid. Posting of multiple votes
  also leads to invalid votes. Preferably your vote (see ballot below) is
  signed with your PGP/GPG key.

  More information about CDK's RFC can be found at
  http://cdk.sourceforge.net/rfc.html, but feel free to ask questions
  at the developers mailling list: cdk...@li....

  The results of the votes will be sent to the developers mailling
  list after 17 September 2002.

  kind regards,

  Egon Willighagen

 START VOTING BALLOT
 =============================================================

  Name:
  Email:
  PGP/GPG key:

  I vote

  [ ] YES
  [ ] NO

  on the acceptance of RFC #4 first posted on 14 August  2002 with the 
  title "Core classes must not check method parameters".  The content of 
  this RFC can be   found at http://cdk.sourceforge.net/rfc4.html.

 =============================================================
 END VOTING BALLOT

[Cdk-devel] CFV: CDK RFC #3 "Tests in org.openscience.cdk.test Use Same Directory Structure as Tested Classes"

[E.L. W. <eg...@sc...>]

Hi all,
 
  time for some more Call For Votes (CFVs). 

  This message closes the discussion on CDK RFC #3 first posted on 
  30 August  2002 with the title "Tests in org.openscience.cdk.test Use Same
  Directory Structure as Tested Classes". Any further proposal about the
  topics in RFC #3 need to be posted as a new RFC.
 
  Any developer and user of CDK is allowed and encouraged to vote. 
  Please send your completed voting ballot (name, email address, and 
  optionally you PGP/GPG key) to cdk...@li... before:
 
    18 September 2002 00:00 GMT
 
  Votes sent to other email addresses are invalid. Posting of multiple votes
  also leads to invalid votes. Preferably your vote (see ballot below) is
  signed with your PGP/GPG key.
 
  More information about CDK's RFC can be found at 
  http://cdk.sourceforge.net/rfc.html, but feel free to ask questions
  at the developers mailling list: cdk...@li....
 
  The results of the votes will be sent to the developers mailling
  list after 17 September 2002.
 
  kind regards,
 
  Egon Willighagen
 
 START VOTING BALLOT
 =============================================================
 
  Name:
  Email:
  PGP/GPG key:
 
  I vote
 
  [ ] YES
  [ ] NO
 
  on the acceptance of RFC #3 posted on 30 August 2002 with the
  title "Tests in org.openscience.cdk.test Use Same Directory Structure as 
  Tested Classes".  The content of this RFC can be
  found at http://cdk.sourceforge.net/rfc3.html.
 
 =============================================================
 END VOTING BALLOT

Re: [Cdk-devel] Interesting OS-Chem overview in German PC!Linux

[Joerg K. W. <we...@in...>]

Hi all,

Two points !;-)
1. Yes the big package is o.k., for the small packages a good readme would work.
2. Jmol: I had not time to test everything for this article, because there was
less time to achieve the given deadline.
I've just forgotten.

> Hi all,
>
> Joerg Wegner (of JOELib) and Thomas Drilling wrote an article in the German
> magazine PC!Linux (which seems a nice magazine, bad too expensive) with the
> title:
>
> "Ueber den Tellerrand"
>
> I do no know what tellerrand is, but the subtitle is clear enough:
>
> "Linux-programme fuer Wirkstoff-Entwicklung unter Linux"
>
> which translates to:
>
> Linux programs for drug design on Linux
>
> (I think the double Linux name is because we can also run Windows
> programs for drug design on Linux, like ChemOffice which runs on
> Linux using Wine ;)
>
> Anyway, a very nice article (five full pages) and describes JChemPaint and
> CDK. Below I'll give the positive and negative aspects mentioned:
>
> JChemPaint:
> "Die Eingabe von SMILES mit anschießender 2D-Struktur-Generierung is
> möglich, jedoch fehlt die Möglichkeit Wasserstoffatome zum Molekül
> hinzufügen zu können."
> The input of SMILES met subsequent structure generation is possible,
> but the possibility to add hydrogen to the molecule is missing.
>
> "Ein Manko stellt die fehlende Unterstützung für erweiterte Atom- und
> Bindungsparameter dar."
> A missing feature is the support for specified atom and bond
> parameters.
>
> Some positive points mentioned: prediction of 13C NMR, downloading
> structures from internet and CML support.
>
> CDK:
> "Durch die Aufsplittung der Pakete zwischen Sourcecode, Java-Bibliotheken
> und dem JUnit test code wurde die Installation aber leider unnötig erschwert."
> Due to the split of the CDK into several packages (source code, Java libraries
> and JUnit tests), the CDK is unnecessarily hard to install.
>
> The article then suggests to use CVS instead... which is better, in my
> opinion, but the point is clear. I was, myself, also not very happy with it,
> but it historically grew. The reason why I originally did this is that the
> needed Java libraries are large and seldomly change. I've now compiled
> a one package CDK dist (See SourceForge cdk-20020831) which still
> downloads in about 5 minutes on a ISDN line (thus ~6-7 on a normal dial up
> connection).
>
> Joerg, does that package fix this point of critisism?
>
> For the rest, there is nothing special mentioned about CDK other than CML
> support and the option to combine it with JChemPaint to predict 13C.
>
> Other java software that is mentioned:
> JOELib                          GPL
> B (formerly Biomer)             "As is"
> MarvinTools                     free for academic use, no source code
> WebMO                           WebMO license, no source code
> WebMol                          free for academic use, with source code
> JMV                                     JMV license, with source code
>
> Other software:  FlexV (free), Gamess98 (costless license), Tinker (As is),
> OpenBabel (GPL), PyMOL (other license), MolScript (acad. free), CACTVS
> (citation), Ghemical (GPL), Rasmol (free), MPQC (GPL) and Molmol (other
> license).
>
> In this list I missed Jmol.
>
> Joerg, was there a reason to leave out Jmol?
>
> That's all.
>
> Egon
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Cdk-devel mailing list
> Cdk...@li...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel

--
Dipl. Chem. Joerg K. Wegner
Univ. Tuebingen, Computer Architecture, Sand 1, D-72076 Tuebingen, Germany
Tel. (+49/0) 7071 29 78970, Fax (+49/0) 7071 29 5091
E-Mail: mailto:we...@in...
WWW:    http://www-ra.informatik.uni-tuebingen.de

[Cdk-devel] CDK RFC #2 Accepted

[E.L. W. <eg...@sc...>]

Hi All,

CDK RFC #2 has been accepted after voting with:

  YES x2
  NO x0

regards,

Egon

Fwd: [Cdk-devel] CDK release 20020831

[Egon W. <eg...@sc...>]

Hi all,

a new CDK version has been released. Among bug fixes
for #588043, #599536 and #599539), this
release has several feature enhancements:

* Added Fragment class (fixes wishlist #591476)
* Added cdk-download program (fixes wishlist #595031)
* Added -t option to cdk-test for textual JUnit output
* Added convertor procedures for CDK from/to jmol.Atom,
  jmol.ChemFrame
* Added support for using Jmol as 3D viewer in cdk-view

Keep in mind that this release has a few API changes:

* Added int[][] AtomContainer.getAdjacencyMatrix() method
* Moved more test classes to subpackages of cdk.test
* Merged IsotopeFactory and ElementFactory
* Made IsotopeFactory a singleton class
* CDKConstants is now a class and no longer an interface

Of these API changes the last four items can mean this you
need to rewrite your own code *if* they:
- use/extend classes in org.openscience.cdk.test
- use the IsotopeFactory class
- use the ElementFactory class (methods are now in IstotopeFactory)
- constants defined by CDKContstants
- implement the CDKContstants interface

Also, the new package is no longer splitted in several smaller packages
The original idea was that the cdk-libs package (the largest package) woulc
be stable over a number CDK releases in order to reduce the download
time. Considering the size of the full package (3.0 Mb) and the number
of times cdk-libs has already changed, the CDK is no longer splitted.

As always, you can download the CDK package from:

	http://sourceforge.net/project/showfiles.php?group_id=20024

The latest package to download is "cdk" version 20020831.

Problems, bugs, wishes can be posted on:

	http://sourceforge.net/tracker/?group_id=20024&atid=120024

Thanx for using CDK!

kind regards,

Egon Willighagen

[Cdk-devel] Interesting OS-Chem overview in German PC!Linux

[Egon W. <eg...@sc...>]

Hi all,

Joerg Wegner (of JOELib) and Thomas Drilling wrote an article in the Germ=
an
magazine PC!Linux (which seems a nice magazine, bad too expensive) with t=
he
title:

"Ueber den Tellerrand"

I do no know what tellerrand is, but the subtitle is clear enough:

"Linux-programme fuer Wirkstoff-Entwicklung unter Linux"

which translates to:

Linux programs for drug design on Linux

(I think the double Linux name is because we can also run Windows
programs for drug design on Linux, like ChemOffice which runs on=20
Linux using Wine ;)

Anyway, a very nice article (five full pages) and describes JChemPaint an=
d
CDK. Below I'll give the positive and negative aspects mentioned:

JChemPaint:
"Die Eingabe von SMILES mit anschie=DFender 2D-Struktur-Generierung is
m=F6glich, jedoch fehlt die M=F6glichkeit Wasserstoffatome zum Molek=FCl
hinzuf=FCgen zu k=F6nnen."
The input of SMILES met subsequent structure generation is possible,
but the possibility to add hydrogen to the molecule is missing.

"Ein Manko stellt die fehlende Unterst=FCtzung f=FCr erweiterte Atom- und
Bindungsparameter dar."
A missing feature is the support for specified atom and bond
parameters.

Some positive points mentioned: prediction of 13C NMR, downloading
structures from internet and CML support.

CDK:
"Durch die Aufsplittung der Pakete zwischen Sourcecode, Java-Bibliotheken
und dem JUnit test code wurde die Installation aber leider unn=F6tig ersc=
hwert."
Due to the split of the CDK into several packages (source code, Java libr=
aries
and JUnit tests), the CDK is unnecessarily hard to install.

The article then suggests to use CVS instead... which is better, in my=20
opinion, but the point is clear. I was, myself, also not very happy with =
it,=20
but it historically grew. The reason why I originally did this is that th=
e=20
needed Java libraries are large and seldomly change. I've now compiled
a one package CDK dist (See SourceForge cdk-20020831) which still
downloads in about 5 minutes on a ISDN line (thus ~6-7 on a normal dial u=
p=20
connection).=20

Joerg, does that package fix this point of critisism?

For the rest, there is nothing special mentioned about CDK other than CML=
=20
support and the option to combine it with JChemPaint to predict 13C.

Other java software that is mentioned:
JOELib				GPL
B (formerly Biomer)		"As is"
MarvinTools			free for academic use, no source code
WebMO				WebMO license, no source code
WebMol				free for academic use, with source code
JMV					JMV license, with source code

Other software:  FlexV (free), Gamess98 (costless license), Tinker (As is=
),=20
OpenBabel (GPL), PyMOL (other license), MolScript (acad. free), CACTVS=20
(citation), Ghemical (GPL), Rasmol (free), MPQC (GPL) and Molmol (other=20
license).

In this list I missed Jmol.

Joerg, was there a reason to leave out Jmol?

That's all.

Egon

[Cdk-devel] Final Call (Was: Call For Votes: RFC #2)

[Egon W. <eg...@sc...>]

Hi all,

this is a final reminder to vote for RFC #2 as explained in the message
below.

kind regards,

Egon Willighagen

On Wednesday 14 August 2002 13:49, Egon Willighagen wrote:
>  Hi all,
>
>  time for the first Call For Votes (CFVs). This message closes the
> discussion on CDK RFC #2 first posted on 22 May 2002 with the title "list
> of core classes". Any further proposal about the topics in RFC #2 need to
> be filed as a new RFC.
>
>  Any developer and user of CDK is allowed and encouraged to vote.
>  Please send your completed voting ballot (name, email address, and
>  optionally you PGP/GPG key) to cdk...@li... before:
>
>    28 August 2002 00:00 GMT
>
>  Votes sent to other email addresses are invalid. Posting of multiple votes
>  also leads to invalid votes. Preferably your vote (see ballot below) is
>  signed with your PGP/GPG key.
>
>  More information about CDK's RFC can be found at
>  http://cdk.sourceforge.net/rfc.html, but feel free to ask questions
>  at the developers mailling list: cdk...@li....
>
>  The results of the votes will be sent to the developers mailling
>  list on 28 August 2002.
>
>  kind regards,
>
>  Egon Willighagen
>
START VOTING BALLOT
=============================================================
 Name:
 Email:
 PGP/GPG key:

 I vote

 [ ] YES
 [ ] NO

 on the acceptance of RFC #2 posted on 22 May 2002 with the
 title "list of core classes". The content of this RFC can be
 found at http://cdk.sourceforge.net/rfc2.html.

=============================================================
END VOTING BALLOT

[Cdk-devel] proposal: PseudoAtom's

[Egon W. <eg...@sc...>]

Hi all,

I received a bug report for a MDL molfile that cannot be read:
An NullPointerException is thrown in IsotopeFactory. I think the problem is 
the R atom in the file... which reflects an arbitrary side chain.
This does not exist in the isotope list ofcourse...

Since the use of psuedo atoms is very useful in drawing structure diagrams
(R, Me, Et, tBu, etc) is might be interesting to have pseudo atoms...

A PseudoAtom class extends a normal Atom and thus can be used normally in any 
code at this moment... However, IsotopeFactory can detect that it is a 
PseudoAtom and will do no configuration, and as a result not fail with a 
NullPointerException...

Comments, other ideas?

Egon

Re: [Cdk-devel] templates?

[Christoph S. <ste...@ic...>]

Egon Willighagen wrote:

> Do I understand correctly that CASE fragment are much smaller? More like 
> functional group like sizes?

Yes, but some fragments might well reach the size of the regular small 
ring fragments (benzene ring, pyrole ring, etc.). We can often derive 
good-list fragments like benzene rings from the spectroscopic data.

> I was also thinking of using those fragments in toolbars for JCP...

Right, I did not think of this. Very reasonable idea.

So, generally I think that an org.openscience.cdk.templates package 
makes sense. Whether we need a structure underneath....
I gues, yes. Maybe grouped by compound classes and other general 
concepts (rings, etc.)

Cheers,

Chris

-- 
Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf)
MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 
Jena, Germany
Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202

What is man but that lofty spirit - that sense of enterprise.
... Kirk, "I, Mudd," stardate 4513.3..

Re: [Cdk-devel] templates?

[Egon W. <eg...@sc...>]

On Friday 23 August 2002 18:52, Christoph Steinbeck wrote:
> Egon Willighagen wrote:
> > On Friday 23 August 2002 15:17, Christoph Steinbeck wrote:
> >>Egon Willighagen wrote:
> >>>for the IUPAC name generator I am in need of off the shell structures...
> >>>Templates that is... I am going to make a template dir containing
> >>>structures of many kinds in the future...
> >>>
> >>>Does it make sense to make this package cdk.templates, or should I make
> >>>it cdk.iupac.templates?
> >>
> >>How will these templates be coded? Hard coded in by small
> >>MoleculeFactory-like code fragements, or will in a chemical file format?
> >>The first version might be faster.
> >
> > Yes, I was planning to do that hard coded... like you did for some
> > tests...
> >
> >>In any case, we might need templates/fragments in more than one place.
> >>Maybe org.openscience.cdk.templates.iupac?
> >
> > Does that make sense? There is not much specific IUPAC about that, other
> > than that it is used for the iupac generator, and probably a future IUPAC
> > parser too... I would say, either cdk.templates then... I will be using
> > subdires, like ringsystems, aminoacids, etc...
>
> I thought it would make sense to distinguish between templates that are
> used (only) for specific purposes. The fragments used in CASE systems
> might be different from those used for the IUPAC generator. There might,
> of course, be overlap.

I have not yet coded any fragment generation code, but those fragments
will probably include actual fragments with open valencies... like for example
a naphtyl group... of course, most such fragments will only have 1 valancy...

Do I understand correctly that CASE fragment are much smaller? More like 
functional group like sizes?

> But I see that this is disputable.

Maybe not ;) /me just want to understand the reasoning behind the dir
layout that is going to be used... (I really hate moving files around in cvs).

> I guess you have to hardcode those fragments which are relevant for the
> name generator in the naming code anyway.

I was also thinking of using those fragments in toolbars for JCP... were you 
can quickly pick a fragment to add to your drawn structure... these would be
the same templates as used in the IUPAC generator... that is the reason why I 
would prefer not to use the cdk.template.iupac name, but something like 
cdk.template.rings ...

> I think in the end both ways have their pros and cons.

Ofcourse, that's why I posted my question...

Egon

Re: [Cdk-devel] templates?

[Christoph S. <ste...@ic...>]

Egon Willighagen wrote:
> On Friday 23 August 2002 15:17, Christoph Steinbeck wrote:
> 
>>Egon Willighagen wrote:
>>
>>>for the IUPAC name generator I am in need of off the shell structures...
>>>Templates that is... I am going to make a template dir containing
>>>structures of many kinds in the future...
>>>
>>>Does it make sense to make this package cdk.templates, or should I make
>>>it cdk.iupac.templates?
>>
>>How will these templates be coded? Hard coded in by small
>>MoleculeFactory-like code fragements, or will in a chemical file format?
>>The first version might be faster.
> 
> 
> Yes, I was planning to do that hard coded... like you did for some tests...
> 
> 
>>In any case, we might need templates/fragments in more than one place.
>>Maybe org.openscience.cdk.templates.iupac?
> 
> 
> Does that make sense? There is not much specific IUPAC about that, other
> than that it is used for the iupac generator, and probably a future IUPAC 
> parser too... I would say, either cdk.templates then... I will be using 
> subdires, like ringsystems, aminoacids, etc...

I thought it would make sense to distinguish between templates that are 
used (only) for specific purposes. The fragments used in CASE systems 
might be different from those used for the IUPAC generator. There might, 
of course, be overlap.

But I see that this is disputable.

I guess you have to hardcode those fragments which are relevant for the 
name generator in the naming code anyway.

I think in the end both ways have their pros and cons.

Cheers,

Chris

Re: [Cdk-devel] templates?

[Egon W. <eg...@sc...>]

On Friday 23 August 2002 15:17, Christoph Steinbeck wrote:
> Egon Willighagen wrote:
> > for the IUPAC name generator I am in need of off the shell structures...
> > Templates that is... I am going to make a template dir containing
> > structures of many kinds in the future...
> >
> > Does it make sense to make this package cdk.templates, or should I make
> > it cdk.iupac.templates?
>
> How will these templates be coded? Hard coded in by small
> MoleculeFactory-like code fragements, or will in a chemical file format?
> The first version might be faster.

Yes, I was planning to do that hard coded... like you did for some tests...

> In any case, we might need templates/fragments in more than one place.
> Maybe org.openscience.cdk.templates.iupac?

Does that make sense? There is not much specific IUPAC about that, other
than that it is used for the iupac generator, and probably a future IUPAC 
parser too... I would say, either cdk.templates then... I will be using 
subdires, like ringsystems, aminoacids, etc...

Egon