Expected behavior for copy.deepcopy to remove explicit H's?

[someonetookmyname]

Hi,

In trying to clone a molecule by either a) mol2 = Chem.rdchem.Mol(mol1) or b) mol2 = copy.deepcopy(mol1), I notice that an explicit H used for stereochemistry designation has been removed and the hash bond has been moved elsewhere (see attached pic). Even though the movement of the hash bond does not change the configuration of the stereocenter, I don't think the explicit H violates any IUPAC drawing rules.

Is this expected behavior? Are other alternations expected/possible under these cloning methods? Is there a way to get a clone without such changes?

I'm using Debian:

librdkit1/stable,now 202009.4-1 amd64 [installed]
python3-rdkit/stable,now 202009.4-1 amd64 [installed]
rdkit-data/stable,now 202009.4-1 all [installed]

Example code (using V2000 mol/sdf as input):

from rdkit import Chem
import copy
w = Chem.SDWriter('testout.sdf')
w.SetForceV3000(True)
mols = Chem.SDMolSupplier('test.sdf')
for mol in mols:
    copymol = copy.deepcopy(mol)
    constructmol = Chem.rdchem.Mol(mol)
	w.write(copymol)
    w.write(constructmol)
w.close()

Thank you for any guidance.

Best,

Andrew

[greglandrum]

Hi @someonetookmyname You are using a quite old version of the RDKit. I can't reproduce what you're reporting or see if it still happens in a newer RDKit version unless you share the input file you used.

[someonetookmyname]

Thanks for the reply, Greg. Below, I've pasted a simple mol/sdf that reproduces for me.

Just fyi, I installed via
sudo apt-get install python3-rdkit librdkit1 rdkit-data
on a fresh install of Debian 11, as per your instructions page.

The 202009.4-1 version looks to be the current stable version in the Debichem packages (https://qa.debian.org/developer.php?login=debichem-devel@lists.alioth.debian.org), explaining my usage. I mention just in case you want to emphasize preference for alternate compile/install methods on your docs page to get more current versions.

If I get a current version compiled before you can test, then I'll post what I find here.

Thanks.

  MJ230500

 10 10  0  0  0  0  0  0  0  0999 V2000
   -1.6071    0.9143    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   -2.3215    0.5018    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   -2.3215   -0.3232    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   -1.6071   -0.7357    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   -0.8926   -0.3232    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   -0.8926    0.5018    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   -1.6072    1.7393    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   -2.3217    2.1518    0.0000 N   0  0  0  0  0  0  0  0  0  0  0  0
   -0.8927    2.1518    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   -0.8927    1.3268    0.0000 H   0  0  0  0  0  0  0  0  0  0  0  0
  1  2  2  0  0  0  0
  2  3  1  0  0  0  0
  3  4  2  0  0  0  0
  4  5  1  0  0  0  0
  5  6  2  0  0  0  0
  6  1  1  0  0  0  0
  1  7  1  0  0  0  0
  7  9  1  0  0  0  0
  7 10  1  6  0  0  0
  7  8  1  0  0  0  0
M  END
>  <id>
1

$$$$

[someonetookmyname]

Hi Greg,
I still get the same result (removal of explicit H and migration of wedge/hash) when using 2023.03.1.
Thanks.
Best,
Andrew

[someonetookmyname]

Hi Greg,
I've resolved this. I didn't realize that SDMolSupplier() had additional arguments, let alone removeHs which defaults to True.
I had been comparing the input SDF to the post-copy structures, not the post-import structure to the post-copy structures.
When I use removeHs=False during import, the explicit H's stay put in both cloning methods.
Apologies for not being aware of that sooner.
Thanks for the help.
Best,
Andrew