On 27/08/2020 20:15, Jason Biggs wrote:
Everything I know about C++ I learned just so that I can write a link
between an interpreted language and the rdkit, so there are definitely
some gaps in my knowledge.
What I'm trying to understand right now is the expected lifetime of an
Atom pointer
On Thu, Aug 27, 2020 at 4:33 PM David Cosgrove
wrote:
> Hi Jason,
> The answer is that when you delete the molecule, the memory it uses is
> flagged as available for re-use, but nothing else happens to it. If you
> then de-reference pointers to it, such as the atoms that are buried in the
>
Hi Mark,
further to Fio's reply, I think the confusion stems from the fact that when
you call AddHs() after MolFromSmiles() no coordinates are actually
generated; these are only generated on the fly for visualization, and hence
are correct before and after AddHs(), as the layout is always
In RDKit, atoms are owned by the molecule. When you ask for:
auto atom = mol->getAtomWithIdx(0);
You are asking for a pointer to memory internally owned by the
RDKit::ROMol. However:
auto mol = RDKit::SmilesToMol("");
creates a new molecule in memory, so it's your job to delete it. This
Hi Jason,
The answer is that when you delete the molecule, the memory it uses is
flagged as available for re-use, but nothing else happens to it. If you
then de-reference pointers to it, such as the atoms that are buried in the
block of memory allocated to the molecule, you may get away with it
On 8/27/2020 3:06 PM, Nils Weskamp wrote:
To add to this: you are looking at the wonderful concept of an
"undefined behavior" in C/C++. There is no guarantee that your example
program will always show the same behaviour.
In more recent versions of C++, you have access to "smart pointers" like
Hi Paolo!
Very helpful to know - I missed this in my google search. Thank you very
much for your prompt answer and for implementing these changes :).
Best,
Fio
On Thu, Aug 27, 2020 at 12:30 PM Paolo Tosco
wrote:
> Hi Fio,
>
> there is an open PR that addresses this and other issues with the
>
To add to this: you are looking at the wonderful concept of an
"undefined behavior" in C/C++. There is no guarantee that your example
program will always show the same behaviour.
In more recent versions of C++, you have access to "smart pointers" like
std::shared_ptr, which basically implement
On 8/27/2020 2:15 PM, Jason Biggs wrote:
What I'm trying to understand right now is the expected lifetime of an Atom
pointer returned by a molecule, for instance by the getAtomWithIdx method.
Based on the documentation, since this method doesn't say the user is
responsible for deleting the
Hi Fio,
there is an open PR that addresses this and other issues with the
TautomerEnumerator:
https://github.com/rdkit/rdkit/pull/3327
As soon as it will be merged in the main trunk this functionality will be
available.
Hope that helps, cheers
p.
On Thu, Aug 27, 2020 at 9:08 PM Fiorella Ruggiu
Everything I know about C++ I learned just so that I can write a link
between an interpreted language and the rdkit, so there are definitely some
gaps in my knowledge.
What I'm trying to understand right now is the expected lifetime of an Atom
pointer returned by a molecule, for instance by the
Hi Mark,
it's best to add the hydrogens first and then set your coordinates:
m=Chem.MolFromSmiles('Nc1nnc2n1CCS2')
m2=rdmolops.AddHs(m, False, True);
Chem.rdCoordGen.AddCoords(m2)
Best,
Fio
On Thu, Aug 27, 2020 at 11:25 AM Mark Mackey wrote:
> Hi all,
>
>
>
> I’m trying to generate a 2D
Hi everyone,
I am cleaning up molecules to import into our database and canonicalizing
the tautomer using rdkit in python. Some cases result in a time-out and do
not go into my except to be caught. I would like to try setting the
maxTautomer to lower than 1000. I found there was no direct option
Hi all,
I'm trying to generate a 2D layout with sensible locations for hydrogens, and
am struggling a bit. If I start from SMILES:
m=Chem.MolFromSmiles('Nc1nnc2n1CCS2')
m2=rdmolops.AddHs(m, False, True);
Then m2 has perfectly sensible 2D cords for the hydrogens. If I use
addCoords=False here
I've encountered a strange problem when doing constrained embedding that
seems to be related to chirality.
The example is here:
https://gist.github.com/tdudgeon/c4604f3ee9124eeec60668b5eefe465e
The molecule being embedded has a single chiral carbon, and while that atom
is tethered, only one of
Dear Paolo,
many thanks for this regex-based answer to my question.
Best,
Jean-Marc
Le 26/08/2020 à 23:34, Paolo Tosco a écrit :
Hi Jean-Marc,
You can strip the valence field from the MolBlock with a regex:
import re
regex = re.compile(r"^(\s*\d+\.\d{4}\s*\d+\.\d{4}\s*\d+\.\d{4} ... \d
16 matches
Mail list logo