From: Peter Murray-R. <pm...@ca...> - 2004-04-24 11:01:17
|
At 13:14 23/04/2004 +0200, E.L. Willighagen wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Friday 23 April 2004 13:06, E.L. Willighagen wrote: > > BTW, is Jumbo4.3 ready for release? That is, can it be distributed with > > CDK, so that I can update the CMLWriter? > >Just spoke with Stefan, the jars that are currently in CDK cvs... cmlAll.jar >has the artistic license, but what about pmrlib.jar and base.jar? Also for >version 4.3? I have copied in cdk-developers, Gemma, Billy and YY since they have all been involved at times. Please everyone make suggestions We have a distrib on the Wiki: http://wwmm.ch.cam.ac.uk/moin/CmlAtNesc and download the ZIP file This is all covered by Artistic but it doesn't explicitly include it in every directory or module. ***We haven't released Jumbo4.3 as a standalone but will do so in a few days (the reasons are not technical). *** Your experience will help There are 2/3 things to notice: - there is now a CIF reader. Since the Tools contain CifTool this needs to be in jars. Jumbo is set up with jars like: jars xerces saxon fop cif cdk cif needs to be in cif/lib/ciflib.jar and needs to be in .jumbo configuration. The distrib as mounted has CIF in another directory. We have sometimes omitted the jars from the distrib as the package is too large for some mailers and also we don't like keeping jars on CVS - it because they sometimes get corrupted. Note also that our jars are not the latest CDK jars. We would be happy for you to try these. There are not many good examples for Tools and Legacy yet so it isn't easy to test these (which is where the main interaction with CDK comes). We are looking closely at workflow - this is now critical - more next week. Feel free to package jumbo if required. Thus it could be sensible to have pmrlib+base+cmlAll.jar as a single package jumbo.jar. Comments The key areas are: - Does jumbo provide what CDK needs? - we need better communication between Jumbo (in Tools) and CDK. The current method of serializing to ASCII XML is probably an overhead - we need a test suite. Billy is developing a workflow for converting CIF and this will test quite a lot of CDK including: - joint the dots with covalent radii (NB I think Jmol may make rather too many bonds here. I will post.to Jmol separately - partition - iteratively apply symmetry and repartition (Billy) - add bond orders (we think we have a bug here but maybe the later versions will change this) - manage atomic/molecule charge. INChI, CIF and MOPAC only have concept of molecular charge. If they have atomic charges they convert to molecular charge. Can CDK handle this? - 2D layout (but ignore H atoms) This is workflow and it should not be expressed in a single monolithic program. One approach is to write a declarative language, a bit like ANT. We already have such a pseudocode in JUMBO - see distrib - which is translated into several target languages <string name="file.root" read="sysin"/> <file name="mols.cif" select="${cif.dir}/${file.root}.${cif.suffix}"/> <fileset name="mols" file="${mols.cif}" /> <foreach select="${mols}" name="cif"> <cml name="cml" convert="CIF" select="${cif}"/> <joinTheDots name="${cml}" covalent="${covalent.file}"/> <splitMols name="splitMols" in="${cml}"/> <count use="${splitMols}" result="nMols"/> <output text="${cif} had ${nMols} molecules"/> <foreach select="${splitMols}" name="splitMol"> <addBondOrder name="${splitMol}"/> </foreach </foreach> This is off-the-top-of-my-head but it shows the idea. We shall have a clearer idea next week after we see workflow tools. They may have already solved this. P. >Egon > >- -- >eg...@sc... >PhD on Molecular Representation in Chemometrics >Nijmegen University >http://www.cac.sci.kun.nl/people/egonw/ >GPG: 1024D/D6336BA6 > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.7 (SunOS) > >iD8DBQFAiPqQd9R8I9Yza6YRAp6PAJ437gpKa/Q//9RqtmOokBlnectxRACeNnlC >aVdtYdhTRroSNiPyUmSWlQk= >=zNT9 >-----END PGP SIGNATURE----- Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: Peter Murray-R. <pm...@ca...> - 2004-04-26 06:51:16
|
At 12:56 23/04/2004 +0200, E.L. Willighagen wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 Further information. >Hi Peter, > >I was talking with Miguel about creating a small CML variant (like CMLMini) >that a reader (Jmol or CDK) could fully support... Something you've >suggested several times, but for which I have not had time yet... cmlMini is now fixed (you will have to wait till tomorrow for the CVS) >I discovered that cmlMini in CVS does not work, because it does not use the >schema.xml format that cmlAll uses... so, I changed that to: > ><?xml version="1.0"?> ><xsd:schema > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > targetNamespace="http://www.xml-cml.org/schema/cml2/mini" > elementFormDefault="qualified" > xmlns="http://www.xml-cml.org/schema/cml2/core"> > <element ref="atom"/> > <element ref="atomArray"/> > <element ref="atomParity"/> > <element ref="bond"/> > <element ref="bondArray"/> > <element ref="bondStereo"/> > <element ref="bondType"/> > <element ref="cml"/> > <element ref="list"/> > <element ref="molecule"/> > <element ref="scalar"/> ></xsd:schema> > >Which was the idea I though... The schema seems to build fine... This is a reasonable approach but suffers from recursive inclusion. If you look at the content models of (say) molecule you will find all sort of things like identifiers, name, label that you don't want. But they have to be included or the schema fails to validate. So in general you only import very simple elements and handcraft the others. This also lets you tune the attributes (possibly including some of our own if CML is not powerful enough. cmlMini looks like: <?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.xml-cml.org/schema/cml2/mini" elementFormDefault="qualified" xmlns="http://www.xml-cml.org/schema/cml2/mini" xmlns:h="http://www.w3.org/2001/XHTML" > <xsd:element name="atom" id="el.atom"> <xsd:annotation> <xsd:documentation> <div class="summary">A simplified atom.</div> <div class="example" href="atom1.xml"/> </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="atomParity" minOccurs="0"/> </xsd:sequence> <xsd:attributeGroup ref="id"/> <xsd:attributeGroup ref="convention"/> <xsd:attributeGroup ref="dictRef"/> <xsd:attributeGroup ref="elementType"/> <xsd:attributeGroup ref="title"/> <xsd:attributeGroup ref="hydrogenCount"/> <xsd:attributeGroup ref="formalCharge"/> <xsd:attributeGroup ref="spinMultiplicity"/> <xsd:attributeGroup ref="x2"/> <xsd:attributeGroup ref="y2"/> <xsd:attributeGroup ref="x3"/> <xsd:attributeGroup ref="y3"/> <xsd:attributeGroup ref="z3"/> </xsd:complexType> </xsd:element> <xsd:element ref="atomParity"/> <!-- etc. --> >But then I get a lot of java compile errors, becauce the java sources require >other 'elements', i.e. other classes, by itself... for example, CMLAtom >requires Name Label, and some others... > >In other words, is it correct that the java source are not fully customized >based on the defined schema? The problem is the examples. The default example for atom is: <atom id="a1" title="O3'" elementType="O" formalCharge="1" hydrogenCount="1" isotope="17" occupancy="0.7" x2="1.2" y2="2.3" x3="3.4" y3="4.5" z3="5.6" convention="abc:chem" dictRef="chem:atom" > <scalar title="dipole" dictRef="ccml:dipole" units="units:debye">0.2</scalar> <atomParity atomRefs4="a3 a7 a2 a4">1</atomParity> <electron id="e1" atomRef="a1" count="2"/> </atom> which refers to scalar, electron and isotope which are not in the schema. That means its validation fails, but worse is that it autogenerate code like atom.appendElectron(CMLElectron) which will not compile. What I have now done is to tune the examples to the schema. The tools remove all attributes and child elements that are not in the schema. That should be OK. The main problem now is the Tools. MoleculeTool with (say) reference CrystalTool. The tools will therefore fail to compile. I think the best thing is to use the standard tools (cmlAll) for the smaller schemas. If there are operations that are not relevant they should probably fail safe. But this is another argument for writing the tools in pseudocode and deleting all components not consistent with a schema. P. >Egon > >- -- >eg...@sc... >PhD on Molecular Representation in Chemometrics >Nijmegen University >http://www.cac.sci.kun.nl/people/egonw/ >GPG: 1024D/D6336BA6 > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.7 (SunOS) > >iD8DBQFAiPZcd9R8I9Yza6YRAtF1AJkBiOBft5MoHs7GQBWHx5oIJ8JF9QCfWKnJ >DaqwxpsvDC2kCmCBNiZ1NzQ= >=J2/B >-----END PGP SIGNATURE----- Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: Miguel H. <mt...@mt...> - 2004-04-24 14:15:26
|
PMR wrote: > - joint the dots with covalent radii (NB I think Jmol may make rather too > many bonds here. I will post.to Jmol separately Jmol should be using the same algorithm as OpenBabel. And the covalent radii values are taken from OpenBabel. If changes need to be made please let me know. (slightly related - A month or two ago there was some question about some of the covalent radii values used in OpenBabel. I don't know if anything ever came out of that) Miguel |
From: Egon W. <eg...@sc...> - 2004-04-25 13:52:25
|
On Saturday 24 April 2004 12:57, Peter Murray-Rust wrote: > At 13:14 23/04/2004 +0200, E.L. Willighagen wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >On Friday 23 April 2004 13:06, E.L. Willighagen wrote: > > > BTW, is Jumbo4.3 ready for release? That is, can it be distributed with > > > CDK, so that I can update the CMLWriter? > > > >Just spoke with Stefan, the jars that are currently in CDK cvs... > > cmlAll.jar has the artistic license, but what about pmrlib.jar and > > base.jar? Also for version 4.3? > > I have copied in cdk-developers, Gemma, Billy and YY since they have all > been involved at times. Please everyone make suggestions > > We have a distrib on the Wiki: > http://wwmm.ch.cam.ac.uk/moin/CmlAtNesc > and download the ZIP file > This is all covered by Artistic but it doesn't explicitly include it in > every directory or module. > > ***We haven't released Jumbo4.3 as a standalone but will do so in a few > days (the reasons are not technical). *** Your experience will help Ok, I see next week wether I will pick up the zip from the above link, or wait until 4.3 is out... BTW, are there many changes with 4.2? > There are 2/3 things to notice: > - there is now a CIF reader. Since the Tools contain CifTool this needs to > be in jars. Jumbo is set up with jars like: > jars > xerces > saxon > fop > cif > cdk > > cif needs to be in cif/lib/ciflib.jar and needs to be in .jumbo > configuration. The distrib as mounted has CIF in another directory. > > We have sometimes omitted the jars from the distrib as the package is too > large for some mailers and also we don't like keeping jars on CVS - it > because they sometimes get corrupted. Forgetting the -kb in the cvs add gives horror... > Note also that our jars are not the latest CDK jars. We would be happy for > you to try these. Yes, I tried to compile with the latest CDK jars... which failed... I'll see if I can make some patches to get it to compile with latest CDK... > There are not many good examples for Tools and Legacy yet > so it isn't easy to test these (which is where the main interaction with > CDK comes). We are looking closely at workflow - this is now critical - > more next week. > > Feel free to package jumbo if required. Thus it could be sensible to have > pmrlib+base+cmlAll.jar as a single package jumbo.jar. Comments Yes, that would be nice... It's easier in our JavaDoc to state it depends on one jar than on three... > The key areas are: > - Does jumbo provide what CDK needs? I guess what we need most at this moment is CMLDOM... At least for writing we currently use it... BTW, a question about that... How can I set the namespace of a CMLNode? I want to root element to have the xmlns attribute when the user asks (*) for it... *) using one of the IOSettings... > - we need better communication between Jumbo (in Tools) and CDK. The > current method of serializing to ASCII XML is probably an overhead CDK -> CML can be done using cdk/libio/Convertor The other way around can still only be done with the method you described above... > - we need a test suite. Billy is developing a workflow for converting CIF > and this will test quite a lot of CDK including: > > - joint the dots with covalent radii (NB I think Jmol may make rather too > many bonds here. I will post.to Jmol separately > - partition > - iteratively apply symmetry and repartition (Billy) > - add bond orders (we think we have a bug here but maybe the later versions > will change this) Yes, I think so... > - manage atomic/molecule charge. INChI, CIF and MOPAC only have concept of > molecular charge. If they have atomic charges they convert to molecular > charge. Can CDK handle this? What do you mean with 'molecular charge'? That's the overal charge? > - 2D layout (but ignore H atoms) That's implemented... but maybe not used by default. Now that I am able to compile Jumbo (for the first time without help from Gemma or YY :), good job that 4.3! ), I will have a look at the classes that use CDK, and adapt it to use recent changes... > This is workflow and it should not be expressed in a single monolithic > program. One approach is to write a declarative language, a bit like ANT. > We already have such a pseudocode in JUMBO - see distrib - which is > translated into several target languages > > <string name="file.root" read="sysin"/> > <file name="mols.cif" select="${cif.dir}/${file.root}.${cif.suffix}"/> > <fileset name="mols" file="${mols.cif}" /> > <foreach select="${mols}" name="cif"> > <cml name="cml" convert="CIF" select="${cif}"/> > <joinTheDots name="${cml}" covalent="${covalent.file}"/> > <splitMols name="splitMols" in="${cml}"/> > <count use="${splitMols}" result="nMols"/> > <output text="${cif} had ${nMols} molecules"/> > <foreach select="${splitMols}" name="splitMol"> > <addBondOrder name="${splitMol}"/> > </foreach > </foreach> Beautifull! > This is off-the-top-of-my-head but it shows the idea. We shall have a > clearer idea next week after we see workflow tools. They may have already > solved this. Egon |
From: Peter Murray-R. <pm...@ca...> - 2004-04-25 18:06:06
|
Just back from an afternoon away... At 15:01 25/04/2004 +0200, Egon Willighagen wrote: >On Saturday 24 April 2004 12:57, Peter Murray-Rust wrote: > > At 13:14 23/04/2004 +0200, E.L. Willighagen wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > > >Hash: SHA1 > > > > > >On Friday 23 April 2004 13:06, E.L. Willighagen wrote: > > > > BTW, is Jumbo4.3 ready for release? That is, can it be distributed with > > > > CDK, so that I can update the CMLWriter? > > > > > >Just spoke with Stefan, the jars that are currently in CDK cvs... > > > cmlAll.jar has the artistic license, but what about pmrlib.jar and > > > base.jar? Also for version 4.3? > > > > I have copied in cdk-developers, Gemma, Billy and YY since they have all > > been involved at times. Please everyone make suggestions > > > > We have a distrib on the Wiki: > > http://wwmm.ch.cam.ac.uk/moin/CmlAtNesc > > and download the ZIP file > > This is all covered by Artistic but it doesn't explicitly include it in > > every directory or module. > > > > ***We haven't released Jumbo4.3 as a standalone but will do so in a few > > days (the reasons are not technical). *** Your experience will help > >Ok, I see next week wether I will pick up the zip from the above link, or >wait >until 4.3 is out... BTW, are there many changes with 4.2? Yes and no. The functionality has been rationalised. the main change is with the autogeneration, etc. Your enthusiasm has catalysed me to turn the tools into pseudocode. > > There are 2/3 things to notice: > > - there is now a CIF reader. Since the Tools contain CifTool this needs to > > be in jars. Jumbo is set up with jars like: > > jars > > xerces > > saxon > > fop > > cif > > cdk > > > > cif needs to be in cif/lib/ciflib.jar and needs to be in .jumbo > > configuration. The distrib as mounted has CIF in another directory. > > > > We have sometimes omitted the jars from the distrib as the package is too > > large for some mailers and also we don't like keeping jars on CVS - it > > because they sometimes get corrupted. > >Forgetting the -kb in the cvs add gives horror... I am fairly sure we use -kb, but... > > Note also that our jars are not the latest CDK jars. We would be happy for > > you to try these. > >Yes, I tried to compile with the latest CDK jars... which failed... I'll see >if I can make some patches to get it to compile with latest CDK... OK - keep in touch > > There are not many good examples for Tools and Legacy yet > > so it isn't easy to test these (which is where the main interaction with > > CDK comes). We are looking closely at workflow - this is now critical - > > more next week. > > > > Feel free to package jumbo if required. Thus it could be sensible to have > > pmrlib+base+cmlAll.jar as a single package jumbo.jar. Comments > >Yes, that would be nice... It's easier in our JavaDoc to state it depends on >one jar than on three... I think we should do this anyway.base+pmrlib+schema ==> jumbo > > The key areas are: > > - Does jumbo provide what CDK needs? > >I guess what we need most at this moment is CMLDOM... At least for writing we >currently use it... BTW, a question about that... How can I set the namespace >of a CMLNode? I want to root element to have the xmlns attribute when the >user asks (*) for it... Good question. the original PMRLib was before namespaces were tested. I suspect I have to fix this. >*) using one of the IOSettings... > > > - we need better communication between Jumbo (in Tools) and CDK. The > > current method of serializing to ASCII XML is probably an overhead > >CDK -> CML can be done using cdk/libio/Convertor > >The other way around can still only be done with the method you described >above... > > > - we need a test suite. Billy is developing a workflow for converting CIF > > and this will test quite a lot of CDK including: > > > > - joint the dots with covalent radii (NB I think Jmol may make rather too > > many bonds here. I will post.to Jmol separately > > - partition > > - iteratively apply symmetry and repartition (Billy) > > - add bond orders (we think we have a bug here but maybe the later versions > > will change this) > >Yes, I think so... OK > > - manage atomic/molecule charge. INChI, CIF and MOPAC only have concept of > > molecular charge. If they have atomic charges they convert to molecular > > charge. Can CDK handle this? > >What do you mean with 'molecular charge'? That's the overal charge? Yes. > > - 2D layout (but ignore H atoms) > >That's implemented... but maybe not used by default. > >Now that I am able to compile Jumbo (for the first time without help from >Gemma or YY :), good job that 4.3! ), I will have a look at the classes that >use CDK, and adapt it to use recent changes... Thanks > > This is workflow and it should not be expressed in a single monolithic > > program. One approach is to write a declarative language, a bit like ANT. > > We already have such a pseudocode in JUMBO - see distrib - which is > > translated into several target languages > > > > <string name="file.root" read="sysin"/> > > <file name="mols.cif" select="${cif.dir}/${file.root}.${cif.suffix}"/> > > <fileset name="mols" file="${mols.cif}" /> > > <foreach select="${mols}" name="cif"> > > <cml name="cml" convert="CIF" select="${cif}"/> > > <joinTheDots name="${cml}" covalent="${covalent.file}"/> > > <splitMols name="splitMols" in="${cml}"/> > > <count use="${splitMols}" result="nMols"/> > > <output text="${cif} had ${nMols} molecules"/> > > <foreach select="${splitMols}" name="splitMol"> > > <addBondOrder name="${splitMol}"/> > > </foreach > > </foreach> > >Beautifull! Good - I will post more later this week. > > This is off-the-top-of-my-head but it shows the idea. We shall have a > > clearer idea next week after we see workflow tools. They may have already > > solved this. > >Egon P. Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: Egon W. <eg...@sc...> - 2004-04-25 17:36:46
|
On Sunday 25 April 2004 18:44, Peter Murray-Rust wrote: > > > We have sometimes omitted the jars from the distrib as the package is > > > too large for some mailers and also we don't like keeping jars on CVS - > > > it because they sometimes get corrupted. > > > >Forgetting the -kb in the cvs add gives horror... > > I am fairly sure we use -kb, but... I can absolutely recommend subversion... It's officially stable now... though it has been quite stable for at least half a year now... It's very easy to setup and in several ways superior to cvs... command (i.e. the 'feel') is mostly identical, but one does not need to care about binary files (it will detect such itself), and one can rename/move files without loosing the history of the file... (end of advertisement :) So when creating a new (jumbo 4.4?) module, consider subversion... <snip> > > > The key areas are: > > > - Does jumbo provide what CDK needs? > > > >I guess what we need most at this moment is CMLDOM... At least for writing > > we currently use it... BTW, a question about that... How can I set the > > namespace of a CMLNode? I want to root element to have the xmlns > > attribute when the user asks (*) for it... > > Good question. the original PMRLib was before namespaces were tested. I > suspect I have to fix this. Thanx. <snip> > > > - manage atomic/molecule charge. INChI, CIF and MOPAC only have concept > > > of molecular charge. If they have atomic charges they convert to > > > molecular charge. Can CDK handle this? > > > >What do you mean with 'molecular charge'? That's the overal charge? > > Yes. Ok, then the answer is 'no'. I.e. the Molecule object does not have an explicit field for overall charge... but, as always setProperty() might be used... Egon |
From: Peter Murray-R. <pm...@ca...> - 2004-04-25 21:42:27
|
At 19:28 25/04/2004 +0200, Egon Willighagen wrote: >On Sunday 25 April 2004 18:44, Peter Murray-Rust wrote: > > > > We have sometimes omitted the jars from the distrib as the package is > > > > too large for some mailers and also we don't like keeping jars on CVS - > > > > it because they sometimes get corrupted. > > > > > >Forgetting the -kb in the cvs add gives horror... > > > > I am fairly sure we use -kb, but... > >I can absolutely recommend subversion... It's officially stable now... though >it has been quite stable for at least half a year now... It's very easy to >setup and in several ways superior to cvs... command (i.e. the 'feel') is >mostly identical, but one does not need to care about binary files (it will >detect such itself), and one can rename/move files without loosing the >history of the file... (end of advertisement :) Thanks Egon, I had never heard of it. A replacement for CVS must be a good thing. It's obviously a bit of work and not our top priority. Some questions: - does Sourceforge use it (else we have to continue to use CVS on SF) - is it better on conflicts in files? - how much effort to install >So when creating a new (jumbo 4.4?) module, consider subversion... > ><snip> > > > > > The key areas are: > > > > - Does jumbo provide what CDK needs? > > > > > >I guess what we need most at this moment is CMLDOM... At least for writing > > > we currently use it... BTW, a question about that... How can I set the > > > namespace of a CMLNode? I want to root element to have the xmlns > > > attribute when the user asks (*) for it... > > > > Good question. the original PMRLib was before namespaces were tested. I > > suspect I have to fix this. > >Thanx. I haven't created namespaces with DOM before. At first glance I use: Document.createElementNS(String namespaceURI, String qualifiedName) and modify it to be used by CMLDocument.createCMLAtom(String namespaceURI, String prefix) Does this look right? Now I feel glad that I have written the autogenerator - should be easy to reconfigure. ><snip> > > > > > - manage atomic/molecule charge. INChI, CIF and MOPAC only have concept > > > > of molecular charge. If they have atomic charges they convert to > > > > molecular charge. Can CDK handle this? > > > > > >What do you mean with 'molecular charge'? That's the overal charge? > > > > Yes. > >Ok, then the answer is 'no'. I.e. the Molecule object does not have an >explicit field for overall charge... but, as always setProperty() might be >used... Since this is standard in QM and some other chemoinformatics (IChI) it is worth thinking about. P. Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: E.L. W. <eg...@sc...> - 2004-04-26 07:16:51
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 25 April 2004 23:38, Peter Murray-Rust wrote: > At 19:28 25/04/2004 +0200, Egon Willighagen wrote: > >I can absolutely recommend subversion... It's officially stable now... > > though it has been quite stable for at least half a year now... It's ve= ry > > easy to setup and in several ways superior to cvs... command (i.e. the > > 'feel') is mostly identical, but one does not need to care about binary > > files (it will detect such itself), and one can rename/move files witho= ut > > loosing the history of the file... (end of advertisement :) > > Thanks Egon, > I had never heard of it. A replacement for CVS must be a good thing. It's > obviously a bit of work and not our top priority. Some questions: > - does Sourceforge use it (else we have to continue to use CVS on SF) No, but the jumbo is not on SF is it? Or do you mirror that in some way? BT= W,=20 I think there are tools to provide subversion access to cvs systems and vis= a=20 versa... I have not explored that. > - is it better on conflicts in files? That mechanism is generally the same... but I think you get better feedback= =20 when files are not up to date... > - how much effort to install Debian has a binary package... Also for RedHat 7.x, 8.0, 9.0 and Fedora 1. See http://subversion.tigris.org/project_packages.html Setting up the system is very easy... see the extensive documentation. > >So when creating a new (jumbo 4.4?) module, consider subversion... > > > ><snip> > > > > > > > The key areas are: > > > > > - Does jumbo provide what CDK needs? > > > > > > > >I guess what we need most at this moment is CMLDOM... At least for > > > > writing we currently use it... BTW, a question about that... How can > > > > I set the namespace of a CMLNode? I want to root element to have the > > > > xmlns attribute when the user asks (*) for it... > > > > > > Good question. the original PMRLib was before namespaces were tested.= I > > > suspect I have to fix this. > > > >Thanx. > > I haven't created namespaces with DOM before. At first glance I use: > Document.createElementNS(String namespaceURI, String qualifiedName) > and modify it to be used by > CMLDocument.createCMLAtom(String namespaceURI, String prefix) > > Does this look right? Yes, I think that's the way to do it... just replace createElement() with=20 createElementNS() > Now I feel glad that I have written the autogenerator - should be easy to > reconfigure. :) Egon =2D --=20 eg...@sc... PhD on Molecular Representation in Chemometrics Nijmegen University http://www.cac.sci.kun.nl/people/egonw/ GPG: 1024D/D6336BA6 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS) iD8DBQFAjLdZd9R8I9Yza6YRAu43AJ4nbDBVgnvDGkbjrA7IHyuVmHngGACgmJUS Wq5hArttzTd8u97wYYC0Mhc=3D =3DiccS =2D----END PGP SIGNATURE----- |
From: E.L. W. <eg...@sc...> - 2004-04-26 07:29:39
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 25 April 2004 23:38, Peter Murray-Rust wrote: > At 19:28 25/04/2004 +0200, Egon Willighagen wrote: > >On Sunday 25 April 2004 18:44, Peter Murray-Rust wrote: > > > > > - manage atomic/molecule charge. INChI, CIF and MOPAC only have > > > > > concept of molecular charge. If they have atomic charges they > > > > > convert to molecular charge. Can CDK handle this? > > > > > > > >What do you mean with 'molecular charge'? That's the overal charge? > > > > > > Yes. > > > >Ok, then the answer is 'no'. I.e. the Molecule object does not have an > >explicit field for overall charge... but, as always setProperty() might = be > >used... > > Since this is standard in QM and some other chemoinformatics (IChI) it is > worth thinking about. What do the others think: should the Molecule object have a field for=20 overallCharge? Egon =2D --=20 eg...@sc... PhD on Molecular Representation in Chemometrics Nijmegen University http://www.cac.sci.kun.nl/people/egonw/ GPG: 1024D/D6336BA6 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS) iD8DBQFAjLpbd9R8I9Yza6YRAnlDAKC7m5LaTBaz+2ZcIXZMxy+Zg3BJhgCeKhnH SGFRs7D0cfVBf+OnpN207mc=3D =3Df79d =2D----END PGP SIGNATURE----- |
From: Christoph S. <c.s...@un...> - 2004-04-26 07:41:14
|
>>>>>>- manage atomic/molecule charge. INChI, CIF and MOPAC only have >>>>>>concept of molecular charge. If they have atomic charges they >>>>>>convert to molecular charge. Can CDK handle this? >>>>> >>>>>What do you mean with 'molecular charge'? That's the overal charge? >>>> >>>>Yes. >>> >>>Ok, then the answer is 'no'. I.e. the Molecule object does not have an >>>explicit field for overall charge... but, as always setProperty() migh= t be >>>used... >> >>Since this is standard in QM and some other chemoinformatics (IChI) it = is >>worth thinking about. >=20 >=20 > What do the others think: should the Molecule object have a field for=20 > overallCharge? If this means having a method iterating over all the atom objects and=20 returning the sum of all atom charges, then I'll vote in favor for that. But I think, getCharge() is just fine. Why "overall". What other type of=20 "charge" which is associated with AtomContainer as a whole could be=20 returned, so that such a word monster would be required :-) Cheers, Chris --=20 Dr. rer. nat. habil. Christoph Steinbeck (c.s...@un...) Groupleader Junior Research Group for Applied Bioinformatics Cologne University BioInformatics Center (http://www.cubic.uni-koeln.de) Z=FClpicher Str. 47, 50674 Cologne Tel: +49(0)221-470-7426 Fax: +49 (0) 221-470-7786 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: E.L. W. <eg...@sc...> - 2004-04-26 07:49:16
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 26 April 2004 09:40, Christoph Steinbeck wrote: > >>>>>>- manage atomic/molecule charge. INChI, CIF and MOPAC only have > >>>>>>concept of molecular charge. If they have atomic charges they > >>>>>>convert to molecular charge. Can CDK handle this? > >>>>> > >>>>>What do you mean with 'molecular charge'? That's the overal charge? > >>>> > >>>>Yes. > >>> > >>>Ok, then the answer is 'no'. I.e. the Molecule object does not have an > >>>explicit field for overall charge... but, as always setProperty() might > >>> be used... > >> > >>Since this is standard in QM and some other chemoinformatics (IChI) it = is > >>worth thinking about. > > > > What do the others think: should the Molecule object have a field for > > overallCharge? > > If this means having a method iterating over all the atom objects and > returning the sum of all atom charges, then I'll vote in favor for that. No, it deals with cases where *only* the molecular charge is given... and n= ot=20 the distribution of charges over the atoms... > But I think, getCharge() is just fine. Why "overall". What other type of > "charge" which is associated with AtomContainer as a whole could be > returned, so that such a word monster would be required :-) Agreed, getCharge() is better... Egon =2D --=20 eg...@sc... PhD on Molecular Representation in Chemometrics Nijmegen University http://www.cac.sci.kun.nl/people/egonw/ GPG: 1024D/D6336BA6 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS) iD8DBQFAjL7rd9R8I9Yza6YRAnW+AJ9ueNNFSVwYEy3RU8oS1aqaknqFbACgofcP RAWoOzDVSR+I5f0dQ05LHTQ=3D =3DIqp2 =2D----END PGP SIGNATURE----- |
From: Kai H. <Kai.Hartmann@Uni-Koeln.De> - 2004-04-26 08:06:33
|
Hi all! >>>>>Since this is standard in QM and some other chemoinformatics (IChI) = it is >>>>>worth thinking about. >>>> >>>>What do the others think: should the Molecule object have a field for >>>>overallCharge? >>> >>>If this means having a method iterating over all the atom objects and >>>returning the sum of all atom charges, then I'll vote in favor for tha= t. >=20 > No, it deals with cases where *only* the molecular charge is given... a= nd not=20 > the distribution of charges over the atoms... >=20 Currently, the iterating methods can be found in org.openscience.cdk.tools.manipulator.AtomContainerManipulator A molecule field would be okay with me. But it should be set every time=20 a structure is read in - together with the atomic formal charges. Maybe=20 a method "assign formal charges to atoms" would have to be run (as Peter=20 suggested), making the I/O process slower. But this way everything would=20 be kept consistent. Bye, Kai --=20 Kai Hartmann CUBIC - Cologne University BioInformatics Center Institute for Biochemistry Z=FClpicher Strasse 47 50674 Koeln Phone: +49-221-470-7719 Fax: +49-221-470-7786 |
From: Peter Murray-R. <pm...@ca...> - 2004-04-26 21:27:35
|
At 09:48 26/04/2004 +0200, E.L. Willighagen wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Monday 26 April 2004 09:40, Christoph Steinbeck wrote: > > >>>>>>- manage atomic/molecule charge. INChI, CIF and MOPAC only have > > >>>>>>concept of molecular charge. If they have atomic charges they > > >>>>>>convert to molecular charge. Can CDK handle this? > > >>>>> > > >>>>>What do you mean with 'molecular charge'? That's the overal charge? > > >>>> > > >>>>Yes. > > >>> > > >>>Ok, then the answer is 'no'. I.e. the Molecule object does not have an > > >>>explicit field for overall charge... but, as always setProperty() might > > >>> be used... > > >> > > >>Since this is standard in QM and some other chemoinformatics (IChI) it is > > >>worth thinking about. > > > > > > What do the others think: should the Molecule object have a field for > > > overallCharge? > > > > If this means having a method iterating over all the atom objects and > > returning the sum of all atom charges, then I'll vote in favor for that. > >No, it deals with cases where *only* the molecular charge is given... and not >the distribution of charges over the atoms... > > > But I think, getCharge() is just fine. Why "overall". What other type of > > "charge" which is associated with AtomContainer as a whole could be > > returned, so that such a word monster would be required :-) > >Agreed, getCharge() is better... in CML it is int getFormalCharge() (fractional charges not allowed). Best P. Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: Peter Murray-R. <pm...@ca...> - 2004-04-26 07:47:30
|
At 09:29 26/04/2004 +0200, E.L. Willighagen wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Sunday 25 April 2004 23:38, Peter Murray-Rust wrote: > > At 19:28 25/04/2004 +0200, Egon Willighagen wrote: > > >On Sunday 25 April 2004 18:44, Peter Murray-Rust wrote: > > > > > > - manage atomic/molecule charge. INChI, CIF and MOPAC only have > > > > > > concept of molecular charge. If they have atomic charges they > > > > > > convert to molecular charge. Can CDK handle this? > > > > > > > > > >What do you mean with 'molecular charge'? That's the overal charge? > > > > > > > > Yes. > > > > > >Ok, then the answer is 'no'. I.e. the Molecule object does not have an > > >explicit field for overall charge... but, as always setProperty() might be > > >used... > > > > Since this is standard in QM and some other chemoinformatics (IChI) it is > > worth thinking about. > >What do the others think: should the Molecule object have a field for >overallCharge? To expand on this... the overall charge on a molecule is (usually) known exactly and not a special convention, whereas atom charges are formal and arbitrary. The only restrictions are that their sum must be the molecule charge. Examples are - cyclopentadienyl [C5H5]- there is no obvious atom to assign a -ve charge to - CH4+. methane radical cation - [HgCl2]- this can be written as Cl-Hg[-]-Cl but it gets messy and error prone. In functional terms we should always be able to extract the molecular charge from a molecule if it is known. Molecule.getChargeFromAtomFormalCharges() It may be useful to have an algorithm: Molecule.assignFormalAtomicCharges() for formats such as MOL and SMILES which don't carry molecule charge P. >Egon > >- -- >eg...@sc... >PhD on Molecular Representation in Chemometrics >Nijmegen University >http://www.cac.sci.kun.nl/people/egonw/ >GPG: 1024D/D6336BA6 > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.7 (SunOS) > >iD8DBQFAjLpbd9R8I9Yza6YRAnlDAKC7m5LaTBaz+2ZcIXZMxy+Zg3BJhgCeKhnH >SGFRs7D0cfVBf+OnpN207mc= >=f79d >-----END PGP SIGNATURE----- Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |