Skip to content

Qchem Module for Cantherm - #255

Closed
enochd wants to merge 7 commits into
ReactionMechanismGenerator:masterfrom
enochd:qchem
Closed

Qchem Module for Cantherm#255
enochd wants to merge 7 commits into
ReactionMechanismGenerator:masterfrom
enochd:qchem

Conversation

@enochd

@enochd enochd commented Jul 21, 2014

Copy link
Copy Markdown
Member

Added a module for cantherm that allows users to perform rate theory calculations with Qchem output files. Similar to the Gaussian module. Added a couple simple examples as well

enochd added 7 commits July 18, 2014 17:41
qchem.py: this new module works reads in information from qchem output
files (e.g., opt+freq jobs, PES scan jobs). In it's present form, it
works, but there is still one more thing that must be added - a read
force constant matrix function. I've been advised to make this commit
earlier rather than later, however. statmech.py is necessarily changed
so that RMG/cantherm recognizes qchem files. In addition, I know I still
have to make unittests, and update the documentation, which I'll get to
shortly. Feel free to test it out and let me know what's wrong.
Rather large example but should still be helpful.
didn't realize the qchem mod was not properly reading in atomic numbers.
Caused cantherm to crash when trying to write cartesian coordinates of
species to the output file
my isopentoxy example is too big (it has 30+ MB of qchem output files),
so I am adding a smaller one. I will add other small ones in the future
that include pdep. Also, I reverted a change in the C2H4+H example back
to what is on the master RMG-Py brach.
it's too big and complicated ...
this one is for a unimolecular decomposition reaction using the Qchem
mod
@connie connie mentioned this pull request Jul 21, 2014
@connie

connie commented Jul 21, 2014

Copy link
Copy Markdown
Member

Reformulated as #256

@connie connie closed this Jul 21, 2014
alongd added a commit to alongd/RMG-Py that referenced this pull request Aug 20, 2026
to_smiles() shortcuts small species through two lookup tables that were keyed
on the chemical formula. A formula says nothing about charge, so any charged
species whose formula matched an entry was handed the neutral species' SMILES,
silently: the O(-.) anion came out as '[O]' and read back at net charge zero,
and H(-) came out as 'H+' - the proton's entry, which is not even parseable
SMILES. Anything keyed on the SMILES (Chemkin and YAML export, species
dictionaries, library matching) therefore saw a different species than the
mechanism contained, and two species differing by an electron could collide
onto one identifier.

The defect was never limited to single atoms, and not to ions either. The O2
anion collided with the neutral biradical's '[O][O]'; cyclic ozone collided
with ozone's '[O-][O+]=O'; the carbene form of CO collided with '[C-]#[O+]'.
Those last two are net-neutral species in the standard libraries, so the
collision reached ordinary neutral chemistry as well as the plasma set.

Both tables are now keyed on the charge signature - the formula together with
the charges the atoms carry. Net charge alone would not do it, because an ion
pair such as H(+).OH(-) is net neutral and would still collide with water.
Every previous entry keeps its exact string; the proton's entry is corrected
from the unparseable 'H+' to '[H+]', matching what SMILES_LOOKUPS already
reads. The electron keeps its entry because no backend can write it: RDKit
raises on element 'e' and OpenBabel emits an unparseable '[ReactionMechanismGenerator#255-]'.

Separately, a written SMILES is now checked against the molecule's net charge
before a backend's output is accepted, so a backend that cannot represent the
charge causes the next backend to be tried and, failing that, an exception -
rather than a wrong-but-parseable string that propagates silently. The check
runs only for charged molecules, so neutral chemistry pays nothing for it.

The adjacency-list path is unchanged; it was correct throughout and is the
reference the SMILES side is now made to agree with.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants