Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bond symmetry number unreliable #12

Closed
rwest opened this issue Dec 22, 2009 · 3 comments
Closed

bond symmetry number unreliable #12

rwest opened this issue Dec 22, 2009 · 3 comments
Labels
Status: Stale This issue is out-of-date and may no longer be applicable Type: Risk of Error

Comments

@rwest
Copy link
Member

rwest commented Dec 22, 2009

Commit 0d83783 hid a bug which should be looked at further.
This is the commit message:

The function Structure.split() returns a list of structures that result from
the splitting. In calculateBondSymmetryNumber(), this function was assumed to
return exactly two structures, which it should if things are going normally.
However, this behavior is not guaranteed, so a check was added to ensure that
exactly two structures are returned from split(). If not, the function returns
1, which is as if it was not called for that bond.

@rwest
Copy link
Member Author

rwest commented Feb 16, 2010

See cb32ce9 and related comments

@rwest
Copy link
Member Author

rwest commented Feb 16, 2010

I think some unit tests for bond symmetry number are in order :-)

enochd added a commit to enochd/RMG-Py that referenced this issue May 16, 2014
Aromaticity is now perceived in calculating cyclic symmetry numbers.
This commit copies a molecule inside `calculateCyclicSymmetryNumber`,
turns it into an rdkit object, finds all the aromatic bonds and atoms.
The same bonds and atoms in the corresponding rmg molecule object are
then redifined so that the alogorithm is using the correct information.

There is one strange thing about this fix that I dont yet understand.
The unittest thinks cyclic symmetry number of dimethylbenzene is 1
(should be 2). On my local machine, the same
`calculateCyclicSymmetryNumber` function gets it correct, at 2. Also,
i'm inadvertantly printing a bit to stdout, and not sure why it's
happening?

relevant to issues ReactionMechanismGenerator#12, ReactionMechanismGenerator#24, ReactionMechanismGenerator#119, ReactionMechanismGenerator#70, ReactionMechanismGenerator#141
connie pushed a commit to connie/RMG-Py that referenced this issue Jul 17, 2014
Aromaticity is now perceived in calculating cyclic symmetry numbers.
This commit copies a molecule inside `calculateCyclicSymmetryNumber`,
turns it into an rdkit object, finds all the aromatic bonds and atoms.
The same bonds and atoms in the corresponding rmg molecule object are
then redifined so that the alogorithm is using the correct information.

There is one strange thing about this fix that I dont yet understand.
The unittest thinks cyclic symmetry number of dimethylbenzene is 1
(should be 2). On my local machine, the same
`calculateCyclicSymmetryNumber` function gets it correct, at 2. Also,
i'm inadvertantly printing a bit to stdout, and not sure why it's
happening?

relevant to issues ReactionMechanismGenerator#12, ReactionMechanismGenerator#24, ReactionMechanismGenerator#119, ReactionMechanismGenerator#70, ReactionMechanismGenerator#141

fixup! added aromaticity recognition for symmetry calcs

Better to avoid casting to string if we can - just check if it is None.

fixup! added aromaticity recognition for symmetry calcs

I think this could have been nasty!
atomType is a mutable object. Suppose it was a Cds atom type. What your code would have done,
is change the label on all Cds atom types to be 'Cb'.
   atom1 -> AtomTypeCds -> label -> 'Cds'
would become
   atom1 -> AtomTypeCds -> label -> 'Cb'
instead of
   atom1 -> AtomTypeCb -> label -> 'Cb'

Because the AtomType objects are shared, I think it would have changed them everywhere,
not just in this copy of this molecule.
enochd added a commit to enochd/RMG-Py that referenced this issue Jul 17, 2014
Aromaticity is now perceived in calculating cyclic symmetry numbers.
This commit copies a molecule inside `calculateCyclicSymmetryNumber`,
turns it into an rdkit object, finds all the aromatic bonds and atoms.
The same bonds and atoms in the corresponding rmg molecule object are
then redifined so that the alogorithm is using the correct information.

There is one strange thing about this fix that I dont yet understand.
The unittest thinks cyclic symmetry number of dimethylbenzene is 1
(should be 2). On my local machine, the same
`calculateCyclicSymmetryNumber` function gets it correct, at 2. Also,
i'm inadvertantly printing a bit to stdout, and not sure why it's
happening?

relevant to issues ReactionMechanismGenerator#12, ReactionMechanismGenerator#24, ReactionMechanismGenerator#119, ReactionMechanismGenerator#70, ReactionMechanismGenerator#141
connie pushed a commit to connie/RMG-Py that referenced this issue Jul 18, 2014
Aromaticity is now perceived in calculating cyclic symmetry numbers.
This commit copies a molecule inside `calculateCyclicSymmetryNumber`,
turns it into an rdkit object, finds all the aromatic bonds and atoms.
The same bonds and atoms in the corresponding rmg molecule object are
then redifined so that the alogorithm is using the correct information.

There is one strange thing about this fix that I dont yet understand.
The unittest thinks cyclic symmetry number of dimethylbenzene is 1
(should be 2). On my local machine, the same
`calculateCyclicSymmetryNumber` function gets it correct, at 2. Also,
i'm inadvertantly printing a bit to stdout, and not sure why it's
happening?

relevant to issues ReactionMechanismGenerator#12, ReactionMechanismGenerator#24, ReactionMechanismGenerator#119, ReactionMechanismGenerator#70, ReactionMechanismGenerator#141

fixup! added aromaticity recognition for symmetry calcs

Better to avoid casting to string if we can - just check if it is None.

fixup! added aromaticity recognition for symmetry calcs

I think this could have been nasty!
atomType is a mutable object. Suppose it was a Cds atom type. What your code would have done,
is change the label on all Cds atom types to be 'Cb'.
   atom1 -> AtomTypeCds -> label -> 'Cds'
would become
   atom1 -> AtomTypeCds -> label -> 'Cb'
instead of
   atom1 -> AtomTypeCb -> label -> 'Cb'

Because the AtomType objects are shared, I think it would have changed them everywhere,
not just in this copy of this molecule.
nickvandewiele pushed a commit to nickvandewiele/RMG-Py that referenced this issue Mar 19, 2015
Aromaticity is now perceived in calculating cyclic symmetry numbers.
This commit copies a molecule inside `calculateCyclicSymmetryNumber`,
turns it into an rdkit object, finds all the aromatic bonds and atoms.
The same bonds and atoms in the corresponding rmg molecule object are
then redifined so that the alogorithm is using the correct information.

There is one strange thing about this fix that I dont yet understand.
The unittest thinks cyclic symmetry number of dimethylbenzene is 1
(should be 2). On my local machine, the same
`calculateCyclicSymmetryNumber` function gets it correct, at 2. Also,
i'm inadvertantly printing a bit to stdout, and not sure why it's
happening?

relevant to issues ReactionMechanismGenerator#12, ReactionMechanismGenerator#24, ReactionMechanismGenerator#119, ReactionMechanismGenerator#70, ReactionMechanismGenerator#141

fixup! added aromaticity recognition for symmetry calcs

Better to avoid casting to string if we can - just check if it is None.

fixup! added aromaticity recognition for symmetry calcs

I think this could have been nasty!
atomType is a mutable object. Suppose it was a Cds atom type. What your code would have done,
is change the label on all Cds atom types to be 'Cb'.
   atom1 -> AtomTypeCds -> label -> 'Cds'
would become
   atom1 -> AtomTypeCds -> label -> 'Cb'
instead of
   atom1 -> AtomTypeCb -> label -> 'Cb'

Because the AtomType objects are shared, I think it would have changed them everywhere,
not just in this copy of this molecule.
@pierrelb pierrelb added the Status: Stale This issue is out-of-date and may no longer be applicable label Aug 28, 2015
@goldmanm
Copy link
Contributor

bond symmetry unit tests are functioning properly.

rwest added a commit that referenced this issue Jun 6, 2023
This is a combination of 12 commits, as we tried everything under the sun to debug the CI.
But they all cancelled out when merged (apart from fixing a typo in a comment)

- This is the 1st commit message:
CI: trying to force ubuntu-20.04 instead of ubuntu-latest (temporary)
While we figure out what's happening, let's try an older ubuntu.
- This is commit message #2:
fixup! CI: trying to force ubuntu-20.04 instead of ubuntu-latest (temporary)
- This is the commit message #3:
Switch back to ubuntu-latest
But leave a 20.04 in the matrix build
- This is the commit message #4:
Trying libstdcxx-ng < 13 in Conda environment.
Trying to debug. If this works it should be put in docker file too.
Or, better, the real cause found and fixed.
- This is the commit message #5:
fix typo in env, undo ubuntu os changes, set gcc version in CI to 6
this system object of this version is being provided by gcc, and the
runners no longer come prepackaged with it since its old (?)
- This is the commit message #6:
it wasn't the gcc version
- This is the commit message #7:
it was the julia version, 1.9.0 is brokey
as reported at conda-forge/julia-feedstock#253
the latest release of julia (1.9.0) is brokey, don't use it (put !=1.9.0 in the environment file)
- This is the commit message #8:
make mac and ubuntu use the same cxx library
- This is the commit message #9:
but what if it was rdkit all along?
- This is the commit message #10:
Revert "but what if it was rdkit all along?" because it wasn't
- This is the commit message #11:
Revert "make mac and ubuntu use the same cxx library" cos it didn't work
- This is the commit message #12:
Revert "it was the julia version, 1.9.0 is brokey" but it wasn't
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Stale This issue is out-of-date and may no longer be applicable Type: Risk of Error
Projects
None yet
Development

No branches or pull requests

3 participants