version solved it.
Best,
Michael
On Thu, Oct 15, 2015 at 6:36 AM, Greg Landrum
wrote:
> Hi Michael,
>
> On Wed, Oct 14, 2015 at 7:06 PM, Michael Reutlinger
> wrote:
>
>>
>> I observed a memory leak while using the RDKit to calculate descriptors
>> for a large libr
Hi,
I observed a memory leak while using the RDKit to calculate descriptors for
a large library of compounds.
I tracked it down to the Ipc descriptor and it is reproducible with this
small script:
from rdkit.ML.Descriptors import MoleculeDescriptors
from rdkit import Chem
calculator = MoleculeD
message to the console.
Best,
Michael
On Wed, Oct 14, 2015 at 4:39 PM, Rocco Moretti
wrote:
> On Wed, Oct 14, 2015 at 12:00 AM, Greg Landrum
> wrote:
>
>>
>> On Mon, Oct 12, 2015 at 10:52 PM, Michael Reutlinger
>> wrote:
>>
>>>
>>> However, I th
C=C
> 1nc(nn1)C
> >>> print 'C/C=C\\n1nc(nn1)C'
> C/C=C\n1nc(nn1)C
>
>
> On Oct 12, 2015, at 4:37 PM, Michael Reutlinger wrote:
>
> Hi all,
>
> I just found an unexpected behaviour in the current RDKit. My input is a
> perfectly valid smiles wit
Hi all,
I just found an unexpected behaviour in the current RDKit. My input is a
perfectly valid smiles with explicitly specified double bond configuration.
Actually, similar smiles were obtained using the RDKit.
The problem is, when submitting the smiles string containing an \n to
MolFromSmiles
drum
wrote:
> Hi Michael,
>
> On Sun, Jul 5, 2015 at 2:43 PM, Michael Reutlinger
> wrote:
>
>>
>> I would like to use a machine learning method with the AP and DP
>> descriptors as described by Robert Sheridan.
>>
>> AP descriptors are the 'at
Dear all,
I would like to use a machine learning method with the AP and DP
descriptors as described by Robert Sheridan.
AP descriptors are the 'atom pair' descriptors from Carhart et al. 1985 and
I think they are already available in RDKIT.
DP 'donor−acceptor pair', called 'BP' in Kearsley et al.
Hi Dimitri,
> *If you have the line numbers* it's something like "head | tail" or a
> 2-line for loop w/ line counter.
That's so inefficient for large files, especially if you have already
parsed them once.
> If it's not a one-off and your upstream keeps generating junk, the
> proper solution
error messages using something like the proposed mechanism.
Best,
Michael
> On May 1, 2015, at 12:01 AM, Michael Reutlinger wrote:
> > However, in some cases this does not help. E.g. when an unknown atom
> (most of the time this is X) is found in the MolBlock the import fails wi
general and somewhat lighter weight, would be
> to ensure that you can always get the text of the last item parsed from a
> ForwardSDMolSupplier (a method like: suppl.GetLastItemText()); this would
> allow you to do whatever special error handling you are interested in doing
>
> -g
Hi all,
I am currently working on a program which needs to process libraries of
large SDF files. One requirement is to always produce a valid output
including the molecule title/name or a specified property for referencing.
With specifying sanitize=False with ForwardSDMolSupplier and using
Chem.S
Dear all,
I noticed a problem with compounds containing Sulfur hexafluoride and
similar groups. Gasteiger charges are contain "-nan" for all atoms.
Here is an example:
In [23]: s = 'c1ccc(cc1)S(F)(F)(F)(F)F'
In [24]: AllChem.ComputeGasteigerCharges(mol)
In [25]: mol.GetAtomWithIdx(0).GetProp("_
Dear all,
I noticed another small issue when importing mol / sd data and calculating
RDKIT descriptors.
There is a difference between direct import and smiles (or second mol-block
conversion):
Take Mercury as an simplified example: [Hg+]
If imported as smiles Descriptors.NumRadicalElectrons() r
13 matches
Mail list logo
