[BlueObelisk-discuss] [BlueObelisk-SMILES] help needed -- SMILES and MMFF94 atom types

[Robert Hanson]

[switching to BlueObelisk-Discuss from BlueOblelisk-Smiles here]

Geoff, I will look at that. What does "fully validated" mean exactly?

I have the SMARTS business for MMFF94 charges working in Jmol now for
getting the atom types -- obviously not validated! -- and I suspect it will
require a bit of hand-crafting.

Egon, I'm using your CDK interpretation of how to handle MMFF94 bci and
pbci. That looks relatively simple.

Still, I would like to know more details. I'll look at that code, Geoff,
and see what I can see about some of those groups. Thanks.

Others with insight into MMFF94 charge calculation?

Bob


On Thu, Apr 26, 2012 at 8:11 PM, Geoff Hutchison

Today I decided I wanted Jmol to be able to generate MEP mapped van der

Waals surfaces, and the way I see to do that is to use the MMFF94
algorithms. Especially because I should be able to easily validate with
PubChem, because their structures are delivered with MMFF94 charges.
Open Babel has a fully validated implementation of MMFF94 and charges,
thanks to Tim Vandermeersch. I think ChemKit also has a full MMFF94
implementation, although you'd have to ask Kyle if he validated it.
The MMFF94 atom types are quite opaque, and I'm not sure they can all be
done via SMARTS. Tim hand-coded the aromaticity model and typing in
src/forcefields/forcefieldmmff94.cpp.
-Geoff

--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: [phone]


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

[Geoffrey Hutchison]

Post by Robert Hanson
Geoff, I will look at that. What does "fully validated" mean exactly?

There's an MMFF94 validation set:
http://ccl.net/cca/data/MMFF94/

This includes 761 structures, plus energies, etc. But one reason I bring this up, is that you can use Babel to generate partial charges (e.g., for mol2 files):
echo "c(s1)ccc1Cl" | babel -ismi --gen3d --partialcharge mmff94 -omol2

In short, feel free to use Babel to generate a pile of MMFF94 charges for testing. IIRC, the structures in the test set also have MMFF94 charges.

Post by Robert Hanson
I have the SMARTS business for MMFF94 charges working in Jmol now for getting the atom types -- obviously not validated! -- and I suspect it will require a bit of hand-crafting.

We'd be interested in testing SMARTS versus the hand-crafted rules in Open Babel.

Hope that helps,
-Geoff

[Robert Hanson]

OK, SMARTS-based MMFF94 charges are now checked in for Jmol.

Obviously the settings are not perfect and will take some tweaking. I'm
sure it's more complicate than I make it out to be -- probably some very
odd definitions in there; certainly some I could not fathom on this first
pass. I haven't taken a full look at OpenBabel's definitions, but I did use
the algorithm in OBForceFieldMMFF94::SetPartialCharges() as my basis (even
though some of that makes almost no sense to me -- for example:

switch (type1) {
case 32:
// 32 OXYGEN IN CARBOXYLATE ANION
// 32 NITRATE ANION OXYGEN
// 32 SINGLE TERMINAL OXYGEN ON TETRACOORD SULFUR
// 32 TERMINAL O-S IN SULFONES AND SULFONAMIDES
// 32 TERMINAL O IN SULFONATES
case 35:
// 35 OXIDE OXYGEN ON SP2 CARBON, NEGATIVELY CHARGED
case 72:
// 72 TERMINAL SULFUR BONDED TO PHOSPHORUS
factor = 0.5f;
break;
case 62:
// 62 DEPROTONATED SULFONAMIDE N-; FORMAL CHARGE=-1
case 76:
// 76 NEGATIVELY CHARGED N IN, E.G, TRI- OR TETRAZOLE ANION
factor = 0.25f;
break;
}

What the heck is that? Convince me that is reasonable! (Or are these not
the MMFF94type numbers in MMFF-I_AppendixB.ascii?)

Jmol's aromatic definition is structural, not electronic, so that certainly
would be one point of difference.

Ideally it would be verified, but for a lot of purposes at least for now
I'll be satisfied with an approximation.

I can get partial charges from MMFF94 far easier from PubChem than I can
from OpenBabel, I think. All I have to do is

load :xxxxx

then save the partial charges in an array and compare them with calculated
values:

load :methanol
A = {*}.partialcharge.all
calculate partialCharge
{*}.partialcharge = A.sub({*}.partialcharge.all)
label %[partialcharge]
print {*}.partialcharge.all.stddev

This will display the differences and print the standard deviation. I must
be doing something right, because I do get this:

$ load :methanol
...
0.0

$ load :acetone
...
8.1649824E-4

$ load ":ethyl acetate"
...
3.9223014E-4

$ load ":benzene"
...
0.0

$ load :pyridine
...
0.0

But I'm sure there are plenty that are problematic.

Caffeine must assign different atom types --

load :caffeine
A = {*}.partialcharge.all
calculate partialCharge
{*}.partialcharge = A.sub({*}.partialcharge.all)
label %[partialcharge]
print {*}.partialcharge.all.stddev
0.10437195

But that's what I expect at this stage. Can't expect everything to be
perfect in a day!

Can I get OpenBabel to report what MMFF94 atom types it is assigning?

Bob

Post by Geoffrey Hutchison

Post by Robert Hanson
Geoff, I will look at that. What does "fully validated" mean exactly?

http://ccl.net/cca/data/MMFF94/
This includes 761 structures, plus energies, etc. But one reason I bring
this up, is that you can use Babel to generate partial charges (e.g., for
echo "c(s1)ccc1Cl" | babel -ismi --gen3d --partialcharge mmff94 -omol2
In short, feel free to use Babel to generate a pile of MMFF94 charges for
testing. IIRC, the structures in the test set also have MMFF94 charges.

Post by Robert Hanson
I have the SMARTS business for MMFF94 charges working in Jmol now for

getting the atom types -- obviously not validated! -- and I suspect it will
require a bit of hand-crafting.
We'd be interested in testing SMARTS versus the hand-crafted rules in Open Babel.
Hope that helps,
-Geoff

--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: [phone]


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

[Robert Hanson]

I'm not understanding the MMFF94 assumptions about formal charges. For
example, I have acetic acid

CC(=O)[O-1]

I believe both of these oxygens are MMFF94 type 32 (O, CARBOXYLATE ANION),
Is that correct? If so, how does MMFF94 handle the two different formal
charges? I'm not seeing that...

Post by Robert Hanson
OK, SMARTS-based MMFF94 charges are now checked in for Jmol.
Obviously the settings are not perfect and will take some tweaking. I'm
sure it's more complicate than I make it out to be -- probably some very
odd definitions in there; certainly some I could not fathom on this first
pass. I haven't taken a full look at OpenBabel's definitions, but I did use
the algorithm in OBForceFieldMMFF94::SetPartialCharges() as my basis (even
switch (type1) {
// 32 OXYGEN IN CARBOXYLATE ANION
// 32 NITRATE ANION OXYGEN
// 32 SINGLE TERMINAL OXYGEN ON TETRACOORD SULFUR
// 32 TERMINAL O-S IN SULFONES AND SULFONAMIDES
// 32 TERMINAL O IN SULFONATES
// 35 OXIDE OXYGEN ON SP2 CARBON, NEGATIVELY CHARGED
// 72 TERMINAL SULFUR BONDED TO PHOSPHORUS
factor = 0.5f;
break;
// 62 DEPROTONATED SULFONAMIDE N-; FORMAL CHARGE=-1
// 76 NEGATIVELY CHARGED N IN, E.G, TRI- OR TETRAZOLE ANION
factor = 0.25f;
break;
}
What the heck is that? Convince me that is reasonable! (Or are these not
the MMFF94type numbers in MMFF-I_AppendixB.ascii?)
Jmol's aromatic definition is structural, not electronic, so that
certainly would be one point of difference.
Ideally it would be verified, but for a lot of purposes at least for now
I'll be satisfied with an approximation.
I can get partial charges from MMFF94 far easier from PubChem than I can
from OpenBabel, I think. All I have to do is
load :xxxxx
then save the partial charges in an array and compare them with
load :methanol
A = {*}.partialcharge.all
calculate partialCharge
{*}.partialcharge = A.sub({*}.partialcharge.all)
label %[partialcharge]
print {*}.partialcharge.all.stddev
This will display the differences and print the standard deviation. I must
$ load :methanol
...
0.0
$ load :acetone
...
8.1649824E-4
$ load ":ethyl acetate"
...
3.9223014E-4
$ load ":benzene"
...
0.0
$ load :pyridine
...
0.0
But I'm sure there are plenty that are problematic.
Caffeine must assign different atom types --
load :caffeine
A = {*}.partialcharge.all
calculate partialCharge
{*}.partialcharge = A.sub({*}.partialcharge.all)
label %[partialcharge]
print {*}.partialcharge.all.stddev
0.10437195
But that's what I expect at this stage. Can't expect everything to be
perfect in a day!
Can I get OpenBabel to report what MMFF94 atom types it is assigning?
Bob

Post by Geoffrey Hutchison

Post by Robert Hanson
Geoff, I will look at that. What does "fully validated" mean exactly?

http://ccl.net/cca/data/MMFF94/
This includes 761 structures, plus energies, etc. But one reason I bring
this up, is that you can use Babel to generate partial charges (e.g., for
echo "c(s1)ccc1Cl" | babel -ismi --gen3d --partialcharge mmff94 -omol2
In short, feel free to use Babel to generate a pile of MMFF94 charges for
testing. IIRC, the structures in the test set also have MMFF94 charges.

Post by Robert Hanson
I have the SMARTS business for MMFF94 charges working in Jmol now for

getting the atom types -- obviously not validated! -- and I suspect it will
require a bit of hand-crafting.
We'd be interested in testing SMARTS versus the hand-crafted rules in Open Babel.
Hope that helps,
-Geoff

--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: [phone]
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: [phone]


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

[Kyle Lutz]

---------- Forwarded message ----------
From: Kyle Lutz <***@gmail.com>
Date: Sat, Apr 28, 2012 at 9:28 PM
Subject: Re: [BlueObelisk-discuss] [BlueObelisk-SMILES] help needed --
SMILES and MMFF94 atom types
To: Robert Hanson <***@stolaf.edu>


Hi Robert,

I'm not understanding  the MMFF94 assumptions about formal charges. For example, I have acetic acid
CC(=O)[O-1]
I believe both of these oxygens are MMFF94 type 32 (O, CARBOXYLATE ANION), Is that correct? If so, how does MMFF94 handle the two different formal charges? I'm not seeing that...

MMFF has it's own definition for formal charges (which can be
non-integral and are closely linked to atom type). For the acetic acid
case, both oxygens would receive a type of 32, a formal charge of 0.5,
and a partial charge of -0.9.

I'd invite you to take a look at the MMFF implementation in chemkit
[1]. The relevant classes are MmffAtomTyper [2] and
MmffPartialChargeModel [3].  Also, there is an example demonstrating
how to use chemkit to assign atom types here [4]. Just change "sybyl"
to "mmff" and it will print out the MMFF atom types which should be
useful in testing out different molecules.

Let me know if you have any questions; I'd be glad to help!

Cheers,
Kyle

[1] http://www.chemkit.org
[2] https://github.com/OpenChemistry/chemkit/blob/master/src/plugins/mmff/mmffatomtyper.cpp
[3] https://github.com/OpenChemistry/chemkit/blob/master/src/plugins/mmff/mmffpartialchargemodel.cpp
[4] http://wiki.chemkit.org/SYBYL_Atom_Types_Example

[Kyle Lutz]

Thanks, Kyle. My idea is to replace that very explicit atom typer with a
SMARTS analysis, and I will check carefully to see that it agrees.
One thing I don't understand is this: Where is the original MMFF94 code? Is
that available? My question is whether this code is an interpretation of
that or an exact duplication of that.

I have never seen the original code and I'm pretty sure that it's not
publicly available. I based my implementation on the (seven?) MMFF
papers and the MMFF94 validation suite which Geoff previously linked.
The MMFF94_opti.log gives a lot of useful output showing atom types,
charges and energies for the calculations. Based on that I created an
XML file [1] with the expected values which I use to test my
implementation.

  N5AX   82  N-OXIDE NITROGEN IN 5-RING ALPHA POSITION
  N5BX   82  N-OXIDE NITROGEN IN 5-RING BETA POSITION
  N5OX   82  N-OXIDE NITROGEN IN GENERAL 5-RING POSITION
For which I am clueless as to what N5AX and N5BX could possibly mean.
I think  your code describes N5OX as $([nD3r5] -- an SP2 N-oxide with
aromatic N in a 5-membered ring. But that doesn't fit the description. First
of all, I don't think you can have an N-oxide in an aromatic 5-membered
ring. you could in a 6-membered ring, but not in a five. What am I missing
there.
Not that I trust the description. Surely the REAL description is the
original MMFF94 code. So rather than look at an interpretation of that, I'd
like to see the original.

As would have I when I was writing chemkit's implementation :-).

Maybe you can just point me to a molecule that does have an atom type of 82.

There are seven molecules containing an atom with type #82 in the
validation suite file. Their names are: DICPUA, DICRAI, FENCOQ,
FUPJUV, FUPKOQ, GAVKOD and KEPKIZ.

Charges: I think what you are saying is that I should totally ignore what a
MOL file has for formal charges and first create a set of starting point
charges.

Yes. However, some of the types for metal atoms (e.g Copper and Iron)
require their partial charges which are read from the file.

I think I should be able to do that with SMARTS instead -- applying
the charge model as necessary on the fly. Certainly looks like everything is
there that I'll need. So thanks for that. Can you give me a hint where the
value of a formal charge is coming from in this?
        chemkit::Real q0 = typer->formalCharge(atom);

It is coming from the formal charge assigned during atom typing. In
the MmffAtomTyper class the setType() method has an optional third
parameter for formal charge which gets stored when the atom type is
assigned. The formalCharge() method just returns the formal charge
that was assigned.

Hope this helps.

Cheers,
Kyle

[1] https://github.com/OpenChemistry/chemkit/blob/master/tests/auto/plugins/mmff/mmff94.expected

[Robert Hanson]

Post by Kyle Lutz
There are seven molecules containing an atom with type #82 in the
validation suite file. Their names are: DICPUA, DICRAI, FENCOQ,
FUPJUV, FUPKOQ, GAVKOD and KEPKIZ.

DICPUA. Of course... Duh. Alright, that's no problem with SMARTS.

Post by Kyle Lutz

Charges: I think what you are saying is that I should totally ignore

what a

MOL file has for formal charges and first create a set of starting point
charges.

Yes. However, some of the types for metal atoms (e.g Copper and Iron)
require their partial charges which are read from the file.

sure.

Ah, so opti_log is in fact exactly what I was looking for. My goal will be
to reproduce this section shown below for each of the 761 compounds:

New Structure Name/Conformational Index: COTPEG

ELECTROSTATIC interactions currently use a CONSTANT dielectric model
The current INTRA- and INTERmolecular dielectric constants are: 1.000
1.000
OPTIMOL> # list
ENTER A LIST SUBCOMMAND OR "HELP"
OPTIMOL-LIST> # ty

ATOM NAME TYPE ATOM NAME TYPE ATOM NAME TYPE ATOM NAME TYPE
O1 #1 32 O2 #2 32 O3 #3 7 O4 #4 7
O5 #5 6 C1 #6 41 C2 #7 3 C3 #8 1
C4 #9 1 C5 #10 3 H5 #11 24 H31 #12 5
H32 #13 5 H41 #14 5 H42 #15 5
OPTIMOL-LIST> # symb

ATOM NAME SYMBOL ATOM NAME SYMBOL ATOM NAME SYMBOL ATOM NAME SYMBOL
O1 #1 O2CM O2 #2 O2CM O3 #3 O=CR O4 #4 O=CO
O5 #5 OC=O C1 #6 CO2M C2 #7 C=OR C3 #8 CR
C4 #9 CR C5 #10 COO H5 #11 HOCO H31 #12 HC
H32 #13 HC H41 #14 HC H42 #15 HC
OPTIMOL-LIST> # char

ATOM CHARGE ATOM CHARGE ATOM CHARGE ATOM
CHARGE

O1 #1 -0.900 O2 #2 -0.900 O3 #3 -0.570 O4 #4
-0.570
O5 #5 -0.650 C1 #6 0.947 C2 #7 0.362 C3 #8
0.061
C4 #9 0.061 C5 #10 0.659 H5 #11 0.500 H31 #12
0.000
H32 #13 0.000 H41 #14 0.000 H42 #15 0.000
OPTIMOL-LIST> # fchar

ATOM FCHARGE ATOM FCHARGE ATOM FCHARGE ATOM
FCHARGE

O1 #1 -0.500 O2 #2 -0.500 O3 #3 0.000 O4 #4
0.000
O5 #5 0.000 C1 #6 0.000 C2 #7 0.000 C3 #8
0.000
C4 #9 0.000 C5 #10 0.000 H5 #11 0.000 H31 #12
0.000
H32 #13 0.000 H41 #14 0.000 H42 #15 0.000

Post by Kyle Lutz
Hope this helps.

Yes, that is totally helpful. Especially the chemkit code. I find analyzing
code is the only way to know exactly what a program does. Sorry to hear
that the MMFF94 source is not available.

I think I'm almost done with the SMARTS business. The interesting thing
about the SMARTS is that it ends up finding all atoms of a given type in
one check rather than running through a double loop of all the possible
types for each atom.

The formal charge business will not be a problem; when I'm done I think I
might have a bug fix or two for you for chemkit, but can't say for sure
right now. That logic looks very good.

I hope to work on this again tonight.

Bob

Post by Kyle Lutz
Cheers,
Kyle
[1]
https://github.com/OpenChemistry/chemkit/blob/master/tests/auto/plugins/mmff/mmff94.expected

--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: [phone]


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

[Robert Hanson]

follow-up on this. Over the last few days I was able to extend this to
fully validated MMFF94 minimization capability in Jmol with empirical
rules. Here's a summary of what I just checked in.

version=12.3.26_dev

# code: adding empirical rules to MMFF94 calculation
#
# checkmm.spt;checkAllEnergies

# checking calculated energies for 761 models
# 1 COMKAQ E= -7.3250003 Eref= -7.6177 diff= 0.2926998
# 2 DUVHUX10 E= 64.759995 Eref= 64.082855 diff= 0.6771393
# 3 FORJIF E= 35.978 Eref= 35.833878 diff= 0.14412308
# 4 JADLIJ E= 25.104 Eref= 24.7038 diff= 0.4001999
# 5 PHOSLA10 E= 111.232994 Eref= 112.07078 diff= 0.8377838
# 6 PHOSLB10 E= -93.479004 Eref= -92.64081 diff= 0.8381958
# 7 OHMW1 E= -20.78 Eref= -21.726902 diff= 0.9469013

# for 761 atoms, 7 have energies differences outside the
# range -0.1 to 0.1 with a standard deviation of 0.06309618


COMKAQ
-- BATCHMIN ignores 1 of 5-membered ring torsions for a
1-oxo-2-oxa-bicyclo[3.2.0]heptane
-- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

DUVHUX10
-- BATCHMIN ignores 5-membered ring issue for S-S-containing ring
-- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

FORJIF
-- BATCHMIN misses four standard 5-membered C-C ring bonds
-- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

JADLIJ
-- BATCHMIN ignores 5-membered ring for S (note, however, this is not the
case in BODKOU)
-- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

PHOSLA10
-- BATCHMIN ignores all 5-membered ring torsions in ring with P
-- (note, however, this is not the case in CUVGAB)
-- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

PHOSLB10
-- BATCHMIN ignores all 5-membered ring torsions in ring with P
-- (note, however, this is not the case in CUVGAB)
-- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

OHMW1
-- H2O complexed with hydroxide OH(-)
-- I don't understand (a) why the OH(-) bond has mltb=1, and even with that
I am not getting the correct ro/kb for that bond from empirical rules.
Still working on that....


I think SMARTS was definitely the way to go on this.
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: [phone]


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

[Geoffrey Hutchison]

follow-up on this. Over the last few days I was able to extend this to fully validated MMFF94 minimization capability in Jmol with empirical rules. Here's a summary of what I just checked in.

Great!

I think SMARTS was definitely the way to go on this.

Well, I may co-opt your SMARTS back for Open Babel. ;-)

OK, I'm stumped. How does one get to Rule d? Does anyone know if this code was ever tested?

That clearly looks like a bug. I forwarded it to Tim, but I haven't heard back from him. Presumably the rule c should be an else if (…) instead of just an else.

-Geoff

---
Prof. Geoffrey Hutchison
Department of Chemistry
University of Pittsburgh
tel: [phone]
email: ***@pitt.edu
web: http://hutchison.chem.pitt.edu/

[Robert Hanson]

Here's my final result. I'm satisfied; I'm pretty sure there is no way to
reproduce the results of the OPTIMOL results exactly. In the cases below
I'm convinced there are bugs in OPTIMOL -- mostly in not consistently
recognizing 5-membered rings, but also there is something odd going on in
the empirical bond parameter calculation.

Bob

# version=12.3.26_dev
#
# code: adding empirical rules to MMFF94 calculation
#
# checkmm.spt;checkAllEnergies
#
# checking calculated energies for 761 models
# 1 COMKAQ E= -7.3250003 Eref= -7.6177 diff= 0.2926998
# 2 DUVHUX10 E= 64.759995 Eref= 64.082855 diff= 0.6771393
# 3 FORJIF E= 35.978 Eref= 35.833878 diff= 0.14412308
# 4 JADLIJ E= 25.104 Eref= 24.7038 diff= 0.4001999
# 5 PHOSLA10 E= 111.232994 Eref= 112.07078 diff= 0.8377838
# 6 PHOSLB10 E= -93.479004 Eref= -92.64081 diff= 0.8381958
#
# for 761 models, 6 have energy differences outside the range -0.1 to 0.1
# with a standard deviation of 0.05309403
#
# a comment about empirical bond parameter calculation:
#
# // Well, guess what? As far as I can tell, in Eqn 18 on page 625,
# // the reduction term and delta are zero.
#
# // -- at least in the program run that is at the validation site:
# // OPTIMOL: Molecular and Macromolecular Optimization Package
17-Nov-98 16:01:23
# // SGI double-precision version ... Updated 5/6/98
# //
# // This calculation is run only for the following three structures. In
each case the
# // reported validation values and values from Jmol 12.3.26_dev are
shown. Clearly
# // the r0 calculated and final energies are very good. subtracting off
0.008 from
# // r0 would certainly not give the reported values. Something is odd
there.
# //
# // bond red* r0(here/valid) kb(here/valid)
Etotal(here/valid)
# //
---------------------------------------------------------------------------------------
# // OHWM1 H1-O1 0.03 0.978/0.978 7.510/7.51
-21.727/-21.72690
# // ERULE_03 Si1-P1 0.0 2.223/2.224 1.614/1.609
-2.983/ -2.93518
# // ERULE_06 N1-F1 0.0 1.381/1.379 5.372/5.438
1.582/ 1.58172
# //
# // *reduction and delta terms not used in Jmol's calculation
#
#
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: [phone]


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900