Better Living Through Chemistry

Getting Started with Better Living Through Chemistry

Better Living Through Chemistry is a Python package that wraps around quantum chemistry programs like Gaussian, GAMESS, and ORCA. It lets you set up calculations, run them, and parse the output without writing shell scripts or manually checking log files every time. The basic workflow is: define a molecule, set up a job, submit it, and extract results. That's it for the happy path. I spent a few years using it in a research group where we were running DFT geometry optimizations on heterocyclic compounds. The first week alone I burned through half a dozen failed jobs because I didn't understand how BLTC handles basis set superposition error corrections by default. It won't do them automatically unless you tell it to, and the documentation is vague about which quantum chemistry backend supports what level of theory.

Why People Actually Use Better Living Through Chemistry

The main draw is automation. If you have fifty molecules to optimize at B3LYP/6-31G*, typing that into Gaussian input files by hand takes forever and introduces errors. BLTC generates the input files for you from a Python dictionary. You can loop through a list of SMILES strings, convert them to 3D coordinates with RDKit, and dispatch everything to a queue. I've seen people cut their setup time from four hours down to maybe twenty minutes for a batch of that size. There's also the parsing side. Instead of grepping through Gaussian output logs for the final energy, BLTC pulls it into a clean data structure. You can query things like optimized geometry, vibrational frequencies, or HOMO-LUMO gaps without wrestling with regex patterns. This part alone is worth the installation hassle. Installation is straightforward if you're on Linux or macOS. The package is on PyPI, so pip install bltc does the trick. On Windows, you'll need WSL or a Docker container because some of the underlying file-watching features don't play nice with NT paths. I learned that the hard way when my first attempt on a lab Windows machine just hung indefinitely during job submission. Switched to Linux and it worked on the second try.

Setting Up Your First Calculation

You start by importing the relevant classes. A typical geometry optimization looks something like this in practice: from bltc import Molecule, GaussianJob mol = Molecule.from_smiles('c1ccccc1', geometry_method='mmff94')

job = GaussianJob(molecule=mol, method='B3LYP', basis='6-31G*', task='opt') job.run() The geometry_method parameter matters more than people admit. MMFF94 is fast but can produce awkward starting geometries for charged or exotic species. If you're working with something like a fluorinated imidazole cation, gencon or even a quick semi-empirical pre-optimization with pm6 gives better convergence. I switched to gencon after my first batch of five benzene derivatives refused to converge on the second optimization cycle.

The run() method blocks until the job finishes. For a small organic molecule at B3LYP/6-31G*, that's usually a few minutes on a modern workstation. Larger systems or tighter convergence criteria can push it to an hour or more. You can set a timeout parameter if you're running this in a pipeline and need to catch hung jobs. One thing the docs don't emphasize enough: BLTC sends jobs to the quantum chemistry program as separate process calls. It doesn't manage clusters or submit to Slurm by itself. If your institution uses a job scheduler, you need to configure the backend separately or write a wrapper script. I ended up writing a small bash wrapper that submits the generated Gaussian input files to Slurm and loops until the .out file appears. Took about thirty lines and saved me from babysitting the terminal.

Parsing Results and Common Pitfalls

After a job completes, you access results through the job object. job.get_energy() returns the final SCF energy in hartrees. job.get_geometry() gives you the optimized coordinates. There are also methods for frequencies, thermochemistry, and molecular orbitals. The API is consistent across backends, which is the main selling point. Here's where things get tricky. When Gaussian encounters a convergence failure, it doesn't always write an error code in a consistent location. BLTC's parser might return None for the energy if the job crashed partway through. I once ran a batch of thirty conjugated polymers and got thirty valid geometries with two of them having NaN energies. The fix was adding a validation step after each job that checks for a nonzero energy and a completed status flag before proceeding. Another subtlety: BLTC assumes your quantum chemistry program is on PATH. If you installed Gaussian in a nonstandard location or you're using a module system like Lmod, you need to add the binary directory to your environment before running anything. I wasted an afternoon debugging a "command not found" error before realizing the Gaussian bin directory wasn't loaded in my shell profile.

For frequency calculations, there's a known issue with imaginary frequencies in transition states. BLTC doesn't automatically distinguish between a real minimum and a first-order saddle point. You need to inspect the vibrational analysis yourself. I write a quick check that counts negative frequencies and flags anything above zero as a possible TS candidate. It's not perfect but it catches the obvious mistakes.

When Better Living Through Chemistry Falls Apart

The package has real limitations. It doesn't support multi-reference methods, so if you're doing CASPT2 or MRCI calculations you're on your own. The ORCA backend is less mature than Gaussian, with fewer parsing features and some missing metadata extraction. I tried switching to ORCA for a speed comparison on a medium-sized system and lost about three hours dealing with incompatible output formats between ORCA 5.x and what BLTC expects from 6.x. Bulk job management is another weak spot. The built-in queuing system is rudimentary. If you need to run hundreds of calculations across multiple nodes, you're better off pairing BLTC with a proper workflow manager like FireWorks or Nextflow. I ended up doing exactly that for a project involving over four hundred transition metal complexes. BLTC handled the individual job generation, but the orchestration layer was custom-built on top of Slurm and MongoDB. The biggest practical limitation is that BLTC is a thin wrapper. It doesn't replace understanding of computational chemistry. If you don't know what B3LYP actually does or why you'd choose def2-TZVP over 6-31G*, the package won't save you from garbage results. I've seen people treat it as a magic black box and then publish geometries that were clearly wrong because they never checked the convergence diagnostics. That's on them, not the software.

For most routine DFT work on organic molecules, it's solid. The installation takes five minutes, the API is reasonable, and the parsing saves genuine time. Just don't expect it to handle edge cases gracefully or replace domain knowledge. The output is only as good as the input you give it, and nobody can automate good science for you. The package is maintained on GitHub under the MIT license. The documentation exists but is sparse on advanced topics. The source code is readable though, and the issue tracker has enough historical context to figure out workarounds for most problems. I keep a personal reference sheet of the methods I use regularly because re-reading the docs every time is slower than just memorizing the common patterns. If you're just getting into computational chemistry and want to automate repetitive tasks, BLTC is a reasonable entry point. If you're doing something unusual or need production-scale job management, plan to build around it rather than expecting it to cover everything.