From: Stefan K. <ste...@eb...> - 2009-03-03 17:16:04
|
Hi all, I found JCP right now adds a fragment to an existing AtomContainer, when you paint e. g. a ring detached from the existing structure. This behaviour causes problems with creating reactions. Obviously the reaction stuff can be changed, but I would prefer to have fragments in the MoleculeSet separatly. What else have we got the MoleculeSet for? Plus in some cases (e. g. the reaction stuff) you would need to do a partitioning, which is costly. But in any case we need a procedure to follow. I vote for one AtomContainer must always be a connected structure. What do you think? Stefan -- Stefan Kuhn B. Sc. M. A. Software Engineer in the Chemoinformatics and Metabolism Team European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2657 Fax +44 (0)1223 494 468 |
From: Egon W. <ego...@gm...> - 2009-03-04 15:43:50
|
On Tue, Mar 3, 2009 at 6:16 PM, Stefan Kuhn <ste...@eb...> wrote: > I found JCP right now adds a fragment What kind of fragments are you taking about? > to an existing AtomContainer, when you > paint e. g. a ring detached from the existing structure. This behaviour > causes problems with creating reactions. What are those problems? > Obviously the reaction stuff can be > changed, but I would prefer to have fragments in the MoleculeSet separatly. How would you need to change the reaction stuff? > What else have we got the MoleculeSet for? A fragment is not a molecule... So, MoleculeSet is not for a set of fragments, I'd say. > Plus in some cases (e. g. the > reaction stuff) you would need to do a partitioning, which is costly. How so? And why is this a problem? Upon deleting a bond you would still have to do this, ...? > But in any case we need a procedure to follow. I vote for one AtomContainer > must always be a connected structure. What do you think? IMolecule has the (unenforced) semantics that it has to be connected. Such requirement has never existed for IAtomContainer. Please explain the problems in more detail... Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |
From: Stefan K. <ste...@eb...> - 2009-03-04 15:58:24
|
On Wednesday 04 March 2009 15:43:40 Egon Willighagen wrote: > On Tue, Mar 3, 2009 at 6:16 PM, Stefan Kuhn <ste...@eb...> wrote: > > I found JCP right now adds a fragment > > What kind of fragments are you taking about? Any sort of thing in JCP, e. g. a ring, a chain, whatever. You can call it molecule or atomcontainer or whatever, I don't care > > > to an existing AtomContainer, when you > > paint e. g. a ring detached from the existing structure. This behaviour > > causes problems with creating reactions. > > What are those problems? If you draw two separate fragments, molecules, atomcontainers or whatever you call them and want to make one the reactant and one the product (which is the natural way to do it in jcp) and you click on the first and say "make reactant in new reaction", both will become one reactant, since make reactant/product operates on atomcontainers. > > > Obviously the reaction stuff can be > > changed, but I would prefer to have fragments in the MoleculeSet > > separatly. > > How would you need to change the reaction stuff? Do a partitioning > > > What else have we got the MoleculeSet for? > > A fragment is not a molecule... So, MoleculeSet is not for a set of > fragments, I'd say. In jcp, this is all interchangeable. What defines a molecule in JCP? Does it suddenly become a molecule if the user finishes? This distinction is not viable in jcp > > > Plus in some cases (e. g. the > > reaction stuff) you would need to do a partitioning, which is costly. > > How so? And why is this a problem? Upon deleting a bond you would > still have to do this, ...? > > > But in any case we need a procedure to follow. I vote for one > > AtomContainer must always be a connected structure. What do you think? > > IMolecule has the (unenforced) semantics that it has to be connected. > Such requirement has never existed for IAtomContainer. And chemmodel contains a MoleculeSet. So right now you can create illegal molecules. > > Please explain the problems in more detail... I hope I made it clear. > > Egon -- Stefan Kuhn B. Sc. M. A. Software Engineer in the Chemoinformatics and Metabolism Team European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2657 Fax +44 (0)1223 494 468 |
From: Egon W. <ego...@gm...> - 2009-03-04 16:19:54
|
On Wed, Mar 4, 2009 at 4:58 PM, Stefan Kuhn <ste...@eb...> wrote: > On Wednesday 04 March 2009 15:43:40 Egon Willighagen wrote: >> On Tue, Mar 3, 2009 at 6:16 PM, Stefan Kuhn <ste...@eb...> wrote: >> > I found JCP right now adds a fragment >> >> What kind of fragments are you taking about? > Any sort of thing in JCP, e. g. a ring, a chain, whatever. You can call it > molecule or atomcontainer or whatever, I don't care But it matters... I understand you mean not "t-Bu", but just an IAtomContainer with IAtoms and IBonds... >> > to an existing AtomContainer, when you >> > paint e. g. a ring detached from the existing structure. This behaviour >> > causes problems with creating reactions. >> >> What are those problems? > If you draw two separate fragments, molecules, atomcontainers or whatever you > call them and want to make one the reactant and one the product (which is the > natural way to do it in jcp) and you click on the first and say "make > reactant in new reaction", both will become one reactant, since make > reactant/product operates on atomcontainers. So, there is a bug in that code: the make reaction action should clearly do a partitioning... it has to convert the model backend anyway... that does not seem to happen right now. Clearly, this functionality has not been ported properly from JCP2 to JCP3. >> > Obviously the reaction stuff can be >> > changed, but I would prefer to have fragments in the MoleculeSet >> > separatly. >> >> How would you need to change the reaction stuff? > Do a partitioning Sure. See above. >> > What else have we got the MoleculeSet for? >> >> A fragment is not a molecule... So, MoleculeSet is not for a set of >> fragments, I'd say. > In jcp, this is all interchangeable. What defines a molecule in JCP? Does it > suddenly become a molecule if the user finishes? This distinction is not > viable in jcp No, but from your writing I understood that you wanted for making that distinction... >> > Plus in some cases (e. g. the >> > reaction stuff) you would need to do a partitioning, which is costly. >> >> How so? And why is this a problem? Upon deleting a bond you would >> still have to do this, ...? >> >> > But in any case we need a procedure to follow. I vote for one >> > AtomContainer must always be a connected structure. What do you think? >> >> IMolecule has the (unenforced) semantics that it has to be connected. >> Such requirement has never existed for IAtomContainer. > And chemmodel contains a MoleculeSet. So right now you can create illegal > molecules. Yes, that would be a correct observation. >> Please explain the problems in more detail... > I hope I made it clear. The current CDK design has some limitations, and if you convert a JCP drawing of one or more molecules into a reaction, you will have to do partitioning. If you like the performance drop because of that or not. Does that answer your questions? Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |
From: Stefan K. <ste...@eb...> - 2009-03-04 16:47:22
|
Well ok, that means we always keep one IMolecule. We can do that and doing partitioning for the reactions is not a real problem, but may I remind you that the IChemModel contains a MoleculeSet. Why have that if not use it? Plus we get invalid IMolecules. As I said I don't really mind, but this is not what I would call good design. Btw, do you remember that at one point in JCP history we explicitly ruled that we would always have connected graphs in the MoleculeSet to avoid partitioning as much as possible. Stefan On Wednesday 04 March 2009 16:19:44 Egon Willighagen wrote: > On Wed, Mar 4, 2009 at 4:58 PM, Stefan Kuhn <ste...@eb...> wrote: > > On Wednesday 04 March 2009 15:43:40 Egon Willighagen wrote: > >> On Tue, Mar 3, 2009 at 6:16 PM, Stefan Kuhn <ste...@eb...> wrote: > >> > I found JCP right now adds a fragment > >> > >> What kind of fragments are you taking about? > > > > Any sort of thing in JCP, e. g. a ring, a chain, whatever. You can call > > it molecule or atomcontainer or whatever, I don't care > > But it matters... I understand you mean not "t-Bu", but just an > IAtomContainer with IAtoms and IBonds... > > >> > to an existing AtomContainer, when you > >> > paint e. g. a ring detached from the existing structure. This > >> > behaviour causes problems with creating reactions. > >> > >> What are those problems? > > > > If you draw two separate fragments, molecules, atomcontainers or whatever > > you call them and want to make one the reactant and one the product > > (which is the natural way to do it in jcp) and you click on the first and > > say "make reactant in new reaction", both will become one reactant, since > > make reactant/product operates on atomcontainers. > > So, there is a bug in that code: the make reaction action should > clearly do a partitioning... it has to convert the model backend > anyway... that does not seem to happen right now. > > Clearly, this functionality has not been ported properly from JCP2 to JCP3. > > >> > Obviously the reaction stuff can be > >> > changed, but I would prefer to have fragments in the MoleculeSet > >> > separatly. > >> > >> How would you need to change the reaction stuff? > > > > Do a partitioning > > Sure. See above. > > >> > What else have we got the MoleculeSet for? > >> > >> A fragment is not a molecule... So, MoleculeSet is not for a set of > >> fragments, I'd say. > > > > In jcp, this is all interchangeable. What defines a molecule in JCP? Does > > it suddenly become a molecule if the user finishes? This distinction is > > not viable in jcp > > No, but from your writing I understood that you wanted for making that > distinction... > > >> > Plus in some cases (e. g. the > >> > reaction stuff) you would need to do a partitioning, which is costly. > >> > >> How so? And why is this a problem? Upon deleting a bond you would > >> still have to do this, ...? > >> > >> > But in any case we need a procedure to follow. I vote for one > >> > AtomContainer must always be a connected structure. What do you think? > >> > >> IMolecule has the (unenforced) semantics that it has to be connected. > >> Such requirement has never existed for IAtomContainer. > > > > And chemmodel contains a MoleculeSet. So right now you can create illegal > > molecules. > > Yes, that would be a correct observation. > > >> Please explain the problems in more detail... > > > > I hope I made it clear. > > The current CDK design has some limitations, and if you convert a JCP > drawing of one or more molecules into a reaction, you will have to do > partitioning. If you like the performance drop because of that or not. > > Does that answer your questions? > > Egon -- Stefan Kuhn B. Sc. M. A. Software Engineer in the Chemoinformatics and Metabolism Team European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2657 Fax +44 (0)1223 494 468 |
From: Stefan K. <ste...@eb...> - 2009-03-04 18:43:06
|
One more observation: Put several detached rings in JCP, you get them all in one. Fine. Then delete any atom and obviously a complete partitioning is done and you have suddenly several IMolecules in the chemmodel. This is a leftover from previous JCP behaviour. Whatever we do - this is inconsistent. I still favor the keep-separate-containers-separate approach, I must admit. Stefan On Wednesday 04 March 2009 16:19:44 Egon Willighagen wrote: > On Wed, Mar 4, 2009 at 4:58 PM, Stefan Kuhn <ste...@eb...> wrote: > > On Wednesday 04 March 2009 15:43:40 Egon Willighagen wrote: > >> On Tue, Mar 3, 2009 at 6:16 PM, Stefan Kuhn <ste...@eb...> wrote: > >> > I found JCP right now adds a fragment > >> > >> What kind of fragments are you taking about? > > > > Any sort of thing in JCP, e. g. a ring, a chain, whatever. You can call > > it molecule or atomcontainer or whatever, I don't care > > But it matters... I understand you mean not "t-Bu", but just an > IAtomContainer with IAtoms and IBonds... > > >> > to an existing AtomContainer, when you > >> > paint e. g. a ring detached from the existing structure. This > >> > behaviour causes problems with creating reactions. > >> > >> What are those problems? > > > > If you draw two separate fragments, molecules, atomcontainers or whatever > > you call them and want to make one the reactant and one the product > > (which is the natural way to do it in jcp) and you click on the first and > > say "make reactant in new reaction", both will become one reactant, since > > make reactant/product operates on atomcontainers. > > So, there is a bug in that code: the make reaction action should > clearly do a partitioning... it has to convert the model backend > anyway... that does not seem to happen right now. > > Clearly, this functionality has not been ported properly from JCP2 to JCP3. > > >> > Obviously the reaction stuff can be > >> > changed, but I would prefer to have fragments in the MoleculeSet > >> > separatly. > >> > >> How would you need to change the reaction stuff? > > > > Do a partitioning > > Sure. See above. > > >> > What else have we got the MoleculeSet for? > >> > >> A fragment is not a molecule... So, MoleculeSet is not for a set of > >> fragments, I'd say. > > > > In jcp, this is all interchangeable. What defines a molecule in JCP? Does > > it suddenly become a molecule if the user finishes? This distinction is > > not viable in jcp > > No, but from your writing I understood that you wanted for making that > distinction... > > >> > Plus in some cases (e. g. the > >> > reaction stuff) you would need to do a partitioning, which is costly. > >> > >> How so? And why is this a problem? Upon deleting a bond you would > >> still have to do this, ...? > >> > >> > But in any case we need a procedure to follow. I vote for one > >> > AtomContainer must always be a connected structure. What do you think? > >> > >> IMolecule has the (unenforced) semantics that it has to be connected. > >> Such requirement has never existed for IAtomContainer. > > > > And chemmodel contains a MoleculeSet. So right now you can create illegal > > molecules. > > Yes, that would be a correct observation. > > >> Please explain the problems in more detail... > > > > I hope I made it clear. > > The current CDK design has some limitations, and if you convert a JCP > drawing of one or more molecules into a reaction, you will have to do > partitioning. If you like the performance drop because of that or not. > > Does that answer your questions? > > Egon -- Stefan Kuhn B. Sc. M. A. Software Engineer in the Chemoinformatics and Metabolism Team European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2657 Fax +44 (0)1223 494 468 |
From: Egon W. <ego...@gm...> - 2009-03-04 18:55:37
|
On Wed, Mar 4, 2009 at 7:43 PM, Stefan Kuhn <ste...@eb...> wrote: > One more observation: Put several detached rings in JCP, you get them all in > one. Fine. Then delete any atom and obviously a complete partitioning is done > and you have suddenly several IMolecules in the chemmodel. This is a leftover > from previous JCP behaviour. Whatever we do - this is inconsistent. I still > favor the keep-separate-containers-separate approach, I must admit. This is exactly why I show hesitative about copy/pasting code from the old JChempaint... Egon -- Post-doc @ Uppsala University http://chem-bla-ics.blogspot.com/ |
From: Stefan K. <ste...@eb...> - 2009-03-05 09:43:35
|
Sorry, I don't think this is the point here. New JCP started with having things separate. Somebody changed the adding of new molecules to be all in one (it used to be separate in new JCP), but left the delete untouched. This is not due to copying, this is due to inconsistent and not well thought changes. And how exactly do you intend things to work? When the delete was added, things were separate. So should we stop doing anything because there might be some changes in some other stuff? Which functions do not depend on others? This means we can do nothing. Many functionality in JCP is the same as in old one, so there is no point in not reusing code. All code I put it is thoroughly checked - which doesn't mean it's error-free, but that's not the case with new code as well. Sure we can stop doing anything, but then we get exactly what I was afraid of all the time: We had a redesign, but no working product. Having a new renderer doesn't make a new JCP. JCP would still be completly unusable without implementing all the functionality. Stefan On Wednesday 04 March 2009 18:55:22 Egon Willighagen wrote: > On Wed, Mar 4, 2009 at 7:43 PM, Stefan Kuhn <ste...@eb...> wrote: > > One more observation: Put several detached rings in JCP, you get them all > > in one. Fine. Then delete any atom and obviously a complete partitioning > > is done and you have suddenly several IMolecules in the chemmodel. This > > is a leftover from previous JCP behaviour. Whatever we do - this is > > inconsistent. I still favor the keep-separate-containers-separate > > approach, I must admit. > > This is exactly why I show hesitative about copy/pasting code from the > old JChempaint... > > Egon -- Stefan Kuhn B. Sc. M. A. Software Engineer in the Chemoinformatics and Metabolism Team European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2657 Fax +44 (0)1223 494 468 |