conformer generation sometimes skips isomer generation [message #1917] |
Wed, 07 June 2023 16:15 ![Go to next message Go to next message](/forum/theme/myThemeWithHFCSS/images/down.png) |
nbehrnd
Messages: 215 Registered: June 2019
|
Senior Member |
|
|
Dear Thomas,
is there a toggle in the program, or perhaps a critical motif in an input structure which prevents DW from altering stereo chemical information while creating conformers?
On re-visit of an old set of random molecules (10mol.dwar, generated by DW, cf. in the attached .zip archive enclosed) which can feature configurations described by R/S, E/Z, P/M, or a combination of them, I noticed the entry `Stereo Isomer` remains equal to `1`. With a newer set of random molecules (Random_Molecules.dwar, equally generated by DW), the anticipated change between the configurations and entries of `Stereo Isomer` different / in addition to the one equal to `1` however take place. The parameters to generate the conformers retain the suggestions, and aim to be the same in both runs.
Both observations refer to DW 5.5.0 for Linux in Linux Debian 12/bookworm including the updates as fetched by yesterday 2023-06-06 / stamped by 2023-05-18. As to document the observations in further detail, the .zip archive attached includes both input and output as provided by DW.
With regards,
Norwid
|
|
|
Re: conformer generation sometimes skips isomer generation [message #1918 is a reply to message #1917] |
Thu, 08 June 2023 14:13 ![Go to previous message Go to previous message](/forum/theme/myThemeWithHFCSS/images/up.png) ![Go to next message Go to next message](/forum/theme/myThemeWithHFCSS/images/down.png) |
thomas
Messages: 694 Registered: June 2014
|
Senior Member |
|
|
Dear Norwid,
the conformation generator does not change any stereo centers. If an input structure contains a racemic stereo center (or an unknown one), then created conformers are allowed to contain any stereo parity at that atom. If an input conformation,
however, has a defined absolute stereo configuration, then all conformers should have this configuration.
Your 10mol.dwar file only contains molecules with given absolute configurations. Thus, all conformers have the same configuration. Random_Molecules.dwar contains exclusively unknown stereo centers. Thus, generated conformers contains all possible stereo isomers.
Part of the reason is that random molecules in the current dev version seem to get unknown stereo configurations, while 5.5.0 generates molecules with absolute configurations. Currently, I don't know why, but I will go back to the old behaviour.
Does this explain it?
Best wishes,
Thomas
[Updated on: Thu, 08 June 2023 14:18] Report message to a moderator
|
|
|
|
Re: conformer generation sometimes skips isomer generation [message #1923 is a reply to message #1919] |
Fri, 09 June 2023 12:14 ![Go to previous message Go to previous message](/forum/theme/myThemeWithHFCSS/images/up.png) |
nbehrnd
Messages: 215 Registered: June 2019
|
Senior Member |
|
|
Dear Thomas,
I do agree with the reasoning to impose a constraint on the conformer generation; to retain stereochemistry assigned as either (R/S), (E/Z), (P/M) in the data submitted in the new set of conformers. Equally, I'm comfortable with the current approach «if ambiguous / a mixture / a racemate, skip this very entry, continue with the next one» your prompt update by 2023-06-08 implements.
After some test runs, I would like to suggest an approach which skips only the entry in the submitted .dwar file which is ambiguous. This is because the submission of `Random_Molecules.dwar` now yields an empty set altogether; there however are some entries DW's internal sketcher recognizes as «this enantiomer». An other which is skipped has no structural CIP relevant motif. With `10mol.dwar` only with entries of an absolute configuration, there is no variation of stereochemistry among the conformers suggested; still, some IDs of the original data set do not appear again among the results. The later observation contrasts with my present anticipation.
For the most recent test run, the previously used instance of DW was removed by `sudo bash ./uninstall.sh`, coherent to the program's documentation. Then, on top of a pristine installation of DW, the update packaged by 2023-06-08 was applied.
With regards,
Norwid
[Updated on: Fri, 09 June 2023 12:15] Report message to a moderator
|
|
|