Better checking for same reactants in KineticsFamily.__generateReactions().

The previous implementation no longer worked because we moved where we make
a temporary copy of the duplicate reactant. The new version uses an
isomorphism check, which is safer. I don't think the speed penalty will be
too significant.

This fixes some incorrect degeneracies, e.g. the disproportionation reaction
C2H5 + C2H5 -> C2H6 + C2H4.
Also check for rate rules with swapped template for R_Recombination reactions.

Rate rules could be specified in either the A + B or B + A order in the
database. I'm not aware of any particular convention for this (or even if
one could be enforced), so we need to check both when looking up the
kinetics. If only one of them gives an exact match, then we will keep that
one. If both are exact or both are estimates, then we keep the one in the
order given; although I don't think this is the best way to do it.

An example is H + CH3 -> CH4, which has an exact rule for (C_methyl,H_rad)
but not for (H_rad,C_methyl). Now you will get the exact rule no matter
which order you specify the template in.
Fix SimpleReactor to use isobaric model.

The new implementation uses total moles instead of concentration for the
y(t) vector. The volume is not stored in y(t) since it can be computed
directly via the ideal gas law from the total moles, and we don't need to
compute dV/dt in this formulation.

I think the previous implementation was actually isochoric instead of
isobaric. Note that the minimal example returns the same result in either
case.
Remove another wild 'import *'
An attempt to fix the "make minimal" target to just do the bare minimum cythoning.

Not sure it works.
Fix initialization of coreSpeciesConcentrations in SimpleReactor

Now that y represents mole numbers not concentrations, the initial
setting of coreSpeciesConcentrations needed to be fixed.
Updated conversion calculations in base solver class.

Now that y represents mole number not concentration, we can remove the 
forced assumption of ideal gas law and just calculate conversion directly
from the number of moles.
Fixed bug in drawing of Network PES.

The bug occurred when trying to condense the space occupied by reactant
channels (placed to the left of the unimolecular isomers). The condensing
caused the reactant isomers to move to the right; we just needed to shift
the entire PES back to the left so that it actually appears in the rendering
window.
Updates to convertFAME.py to make it work with new CanTherm.

Mostly updating the names of a few existing fields and the adding of a few
new fields.
Better handling of very large barrier heights in hindered rotors.

The partition function of a hindered rotor involves a modified Bessel
function of the first kind, I0(z). This function overflows above z = 700;
however, there is a nice series expansion for exp(-z) * I0(z) with less than
0.1% error above x = 100, so we now use that for very large z. (z = V0/2RT)
Add command-line option to control generation of plots in CanTherm.

You will now only get plots of thermo, kinetics, and k(T,P) values if you
provide the -p or --plot command-line argument. Note that you will still get
a drawing of the PES in pdep jobs either way.
Can now prune network in convertFAME.py using -x flag.

You use -x to specify an energy (magnitude and units) above which any
configurations or reaction barrier heights are removed during the conversion
of a FAME input file to a CanTherm input file. This helps crop some of the
more bizarre species that RMG-Java comes up with (e.g. triradicals), leading
to a more tractable PES.
Add an E0 attribute to the Thermo property base class.

All thermo properties (ThermoData, NASA, Wilhoit, etc.) should now have this.
It is currently not set by initiation but has to be set afterwards.
Currently this data is only stored on the Conformer stored within a Species 
(eg. species.conformer.E0 rather than species.thermo.E0). I hope storing it 
in the thermo will improve both
1) parallelization (the "estimate thermo" routines will have no side effects
   besides updating the thermo object which they return.
2) QM thermo (where we should be able to extract the E0 from the QM calculation log)
Add the E0 property to all Thermo (HeatCapacityModel) classes.

It is now in the construction signature of these classes where it should 
be specified (NASA, and ThermoData). For Wilhoit it is the same as H0 and
so should not be specified (it is calculated when you fit the Wilhoit. If you wish
to specify manually, change H0).
Added E0 to Thermo unit tests.

Many work, but the conversion between NASA/Wilhoit/ThermoData is poor to say the least.
E0 varies by hundreds of kJ/mol!
Change the way Wilhoit class stores/calculates E0

The constant of integration H0 is not equal to the enthlapy at 0K,
so the parameter E0 has to be calculated instead of just returning H0.
Fix Thermo conversion unit tests.

Some of the constants in the setup were inconsistent. I think these are now right.
I also added two "round trip" conversion tests, that go from Wilhoit back to Wilhoit
either via NASA or ThermoData. These now all pass.
(I had to loosen the "almost" equal tolerance for E0, but I think 10 or 20 J/mol is ok)
Fix Wilhoit unit tests for new E0 behavior.
Use E0 on new Wilhoit class to set Conformer energy.
Increase limit for warning about poor heat capacity fits.

This is not a very helpful warning.
How high is too high? What impact does it have? What can we do about it anyway?