#429 Allow SmilesGenerator to output aromatic SMILES and also mak

Needs_Revision
closed
John May
cdk-1.4.x (181)
master
7
2013-10-22
2011-10-05
No

The two patches modify the SmilesGenerator to

1) allow the generation of aromatic fragments
2) Not modify (mostly) the input molecule.

1) is achieved by changing the meaning of the useAromaticityFlag to be more obvious: if set to FALSE, the SG will perceieve aromaticity. If set to TRUE, it will use whatever flags are specified in the input molecule. So if you have benzene, but did not perceive aromaticity you will get a non-aromatic SMILES. Also made ring perception and ato typing independent of this flag

2) is achieved by using a clone of the input, but only in createSMILESWithoutCheckForMultipleMolecules. This means that if you call createSmiles, the inputmolecule is changed - but onlhy n the VISITED flag. To make this cleaner, we either make createSMILESWithoutCheckForMultipleMolecules private and clone the molecule in createSmiles;

Related

Patches: #429

Discussion

  • Rajarshi Guha

    Rajarshi Guha - 2011-10-05

    Also added appropriate unit tests and modifed some other unit tests to take this behavior into account. Also updated main Javadocs

     
  • Egon Willighagen

    Rajarshi, I am against the solution for 1, because:

    1. it changes the current implementation (OK in master, but I do not like that in cdk-1.4.x)
    2. it no longer is possible to not have aromatic SMILES if your input was 'wrong'

    Yet, I agree that the useAromaticityFlag was ambigously named. I always interpreted this boolean as the flag to indicate that the generation should use the aromaticity information to create 'aromatic SMILES', but understand your interpretation fully too.

    I suggest two flags, on the basis of my second argument:

    • useAromaticityFlag → indicating that the IChemObject flag CDKConstants.IS_AROMATIC should be used, rather than doing perception itself
    • outputAromaticSmiles → indicating if aromatic or non-aromatic SMILES should be generated.

    This changes the API too. Both options must be reviewed by a second reviewer, but up front, the above is my suggested revision.

     
  • Rajarshi Guha

    Rajarshi Guha - 2011-10-08

    Hmm, I see your point in 1). However., I'd argue that the proposed match makes the 1.4 API "sensible".

    Not sure what you mean in point 2.

    I don't see a problem with adding an extra flag, but I'd rather see that the current useAromaticityFlag be fixed. I that means shifting to master that's fine with me

     
  • Egon Willighagen

    Sorry for not being clear. If you add a second flag, then I'm fine with changing the API to make it sensible for 1.4.x.

    About point 2... if I understand your one-param solution correctly, it was no longer possible to have no perceived aromaticity at all anymore, because both TRUE and FALSE would perceive arom, just in different ways. This too would be fixed by having two params.

     
  • Egon Willighagen

    • assigned_to: Rajarshi Guha --> John May
    • Branch: --> master
     
  • Egon Willighagen

    John, is this patch still relevant?

     
  • John May

    John May - 2013-10-21

    No - the new generator isn't picky now. I do plan to make a 'strict' utility which ensures people don't generate aromatic fragments - this is a really really bad idea as bond assigning orders will likely not be assignable. I explained this elsewhere but will again incase someone finds it. If you want to write an aromatic fragments you're better to write the molecule whole and store the atom numbers.

    c1cc[nH]c1 1,2,3

    or use the atom classes

    c1c[c:1][nH:1][c:1]1

    I think the use case is to store the 'unique' fragments but there are better methods to do this.

    On 21 Oct 2013, at 20:49, Egon Willighagen egonw@users.sf.net wrote:

    John, is this patch still relevant?

    [patches:#429] Allow SmilesGenerator to output aromatic SMILES and also mak

    Status: open
    Labels: cdk-1.4.x
    Created: Wed Oct 05, 2011 02:33 PM UTC by Rajarshi Guha
    Last Updated: Mon Oct 08, 2012 03:43 PM UTC
    Owner: John May

    The two patches modify the SmilesGenerator to

    1) allow the generation of aromatic fragments
    2) Not modify (mostly) the input molecule.

    1) is achieved by changing the meaning of the useAromaticityFlag to be more obvious: if set to FALSE, the SG will perceieve aromaticity. If set to TRUE, it will use whatever flags are specified in the input molecule. So if you have benzene, but did not perceive aromaticity you will get a non-aromatic SMILES. Also made ring perception and ato typing independent of this flag

    2) is achieved by using a clone of the input, but only in createSMILESWithoutCheckForMultipleMolecules. This means that if you call createSmiles, the inputmolecule is changed - but onlhy n the VISITED flag. To make this cleaner, we either make createSMILESWithoutCheckForMultipleMolecules private and clone the molecule in createSmiles;

    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/cdk/patches/429/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

     

    Related

    Patches: #429

  • Egon Willighagen

    Yeah, sorry, should have remembered that :(

     
  • John May

    John May - 2013-10-22

    Okay - closing.

     
  • John May

    John May - 2013-10-22
    • status: open --> closed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks