trying to get DASPK sensitivity analysis to work with time goal (vs. conversion goal)

I'm surprised if this worked before...if it did, perhaps it was due to a compiler difference wherein originally the if loop was failing first (time) criterion and not bothering to check Y(IMPSPECIES) with IMPSPECIES=-1
tried to address compile-time syntax errors/warnings from 511c131aedc53291e4cabfaf28f8518c4f3fe1f1
added missing END IF statement in updated DASPK code

(cf. 511c131aedc53291e4cabfaf28f8518c4f3fe1f1)
example updated to reflect ThermoDataEstimator changes

The input file in the /examples/ThermoDataEstimator/ folder
for the TDE now includes a section with flags for
the on-the-fly generation of thermodynamic properties:

-a QM flag: true/false: activate on-the-fly thermo
-a method: both/gaussian03/mopac/mm4/mm4hr
-ForCyclicsOnly flag: use QM only for cyclic species
-MaxRadNumForQM fag: use QM only for species with a maximum
number of unpaired electrons. (usually, set to 0, to prevent
radicals from being calculated on-the-fly)
Merge pull request #199 from nickvandewiele/master

updated example of ThermoDataEstimator. 
TDE extended to set atom constraints for candidate molecules

The input file of the TDE now has a section were atom constraints,
e.g. max. # of carbons per species etc..., can be set.

new TDE method is based on ChemGraph.readAtomTypes method

When a species does not fulfill the atom constraints, a error will
be thrown and TDE will crash in an unelegant way. This can be fixed
more elegantly.

END keyword has to end the atom constraints section of the input file

example input from /examples/ThermoDataEstimator is updated as well.

Signed-off-by: Nick Vandewiele <nickvandewiele@gmail.com>
END keyword un-commented in /qm/input.txt file

END keyword must be present after (optional) atom constraints
It is not optional.
Merge pull request #200 from nickvandewiele/master

TDE extended to set atom constraints, instead of default values from ChemGraph

This looks ok to me.
It does require an additional "END" line be added to everyone's ThermoDataEstimator input files.
Do we have documentation for this module, or just the example files?
PopulateReactionsServer is much more robust. Reports errors rather than crashing.

First problem was that the Logger had not been initialized, so there was no 
log file, so calls to Logger.error() cause it to die.

Second, was that malformed input would kill the server instead of just that 
request. Now the whole servery loop is wrapped in a try/catch block with 
some exception handling.
Logger shouldn't cause crashes when asked to log a warning or error.

It used to crash if the log file had not been initialized. This was the case
in various ancillary classes like PopulateReactions etc. It is still preferable
to call Logger.initialize() at the start of these classes, but if you don't 
at least the logger will no longer cause your code to crash.

It used to cause things like:
Exception in thread "main" java.lang.NullPointerException
    at jing.rxnSys.Logger.flush(Logger.java:120)
    at jing.rxnSys.Logger.log(Logger.java:191)
    at jing.rxnSys.Logger.error(Logger.java:213)
Replace System.exit(0) with RuntimeException so that the PopulateReactionsServer can catch it.

The server is designed to be robust - it has the inner loop wrapped in a 
"catch everything Throwable" block - but if something calls System.exit(0)
then there's nothing it can do and the server goes offline. Bad.

There are probably more instances of this elsewhere :(
PopulateReactionsServer shell script no longer tees to RMG.log

Now that the class initializes the logger module, stuff is already saved
to the RMG.log file, so this is redundant and confusing.
Backported better method of choosing reservoir cutoffs in RS method.

Previously we were choosing the cutoff to be a few dEdown below the lowest
transition state barrier for each unimolecular isomer. In reality, the
energy grains between that cutoff and the transition state barrier aren't
really in pseudo-steady state either, so we might as well place the cutoff
at the barrier height exactly. (We made this change in MEASURE quite a
while ago, so I'm fairly confident that it won't harm anything.)

The result is that the sensitivity of the k(T,P) values to the dEdown is
significantly diminished for the RS method.
Logger can cope with null messages, without crashing.
Print fame errors to error log, if there are any. (may help debugging)
If there are no HighPKinetics, don't try to print them in PDepArrheniusKinetics rates.

It'd be nice to have the high P limits stored in HighPKinetics for path reactions,
but it currently isn't, and well-skipping pathways will never have them anyway.

Hopefully closes #196
remove key pre-existing input/output files during InChI generation

this is designed for issue #201 and should avoid hidden bugs and make the source of failures more obvious
Better error messages when fame.exe returns incomplete results.

When BufferedReader br reaches the end of the fame output, br.readLine() returns
null. This used to cause NullPointerExceptions. Now it should give a nice
PDepException.
Merge remote-tracking branch 'official/master'
Fixed typo in PDep error message construction. 

When reporting "expected X but only got Y net reactions" the X and Y were reversed.
This was introduced in ef8b7562e99e3d033e019f1b18831e3b833dbbe3