Experimental And Theoretical Studies Of Tetramethoxy-p-benzoquinone: Infrared Spectra, Structural And Lithium Insertion Properties

Published earlier this year in RSC Advances (RSC Adv., 2013, 3, 19081-19096), a follow-up (for my part) to the study The Low-/Room-temperature Forms Of The Lithiated Salt Of 3,6-dihydroxy-2,5-dimethoxy-p-benzoquinone: A Combined Experimental And Dispersion-Corrected Density Functional Study in CrystEngComm last year. The theoretical section for this paper is a tour-de-force of Crystal09 solid-state optimizations, density functional and dispersion-correction dependence, and post-processing using Carlo Gotti’s TOPOND software. In brief, the combination of vibrational spectra, electochemical measurements, and solid-state density functional theory tests are used to predict the structure of the previously unknown lithiated tetramethoxy-p-benzoquinone structure based on the good-to-excellent agreement with two known TMQ crystal structures (the testing of density functionals and dispersion corrections being a very good survey of the pros and cons of the varied methods. If you were pondering an approach to follow to perform the same kind of theoretical analysis, the procedure set up by Gaetan and Christine in this paper is fully worth your consideration).


Gaetan Bonnard, Anne-Lise Barres, Yann Danten, Damian G. Allis, Olivier Mentre, Daniele Tomerini, Carlo Gatti, Ekaterina I. Izgorodina, Philippe Poizot and Christine Frayret*

In the search for low-polluting electrode materials for batteries, the use of redox-active organic compounds represents a promising alternative to conventional metal-based systems. In this article we report a combined experimental and theoretical study of tetramethoxy-p-benzoquinone (TMQ). In carbonate-based electrolytes, electrochemical behaviour of this compound is characterized by a reversible insertion process located at approximately 2.85 V vs. Li+/Li0. This relatively high potential reactivity, coupled with our effort to develop computational methodologies in the field of organic electrode materials, prompted us to complement these experimental data with theoretical studies performed using density functional theory (DFT). Single crystals of TMQ were synthesized and thoroughly characterized showing that this quinonic species crystallised in the P21/n space group. The experimental crystal structure of TMQ was then used to assess various DFT methods. The structural features and vibrational spectra were thus predicted by using as a whole five common density functionals (PBE, LDA, revPBE, PBEsol, B3PW91) with and without a semi-empirical correction to account for the van der Waals interactions using either Grimme’s (DFT-D2) or Tkatchenko-Scheffler (TS) scheme. The most reliable combination of the DFT functional and the explicit dispersion correction was chosen to study the Li-intercalated molecular crystal (LiTMQ) with the view of indentifying Li insertion sites. A very close agreement with the experiment was found for the average voltage by using the most stable relaxed hypothetical LiTMQ structure. Additionally, a comparison of vibrational spectra gained either for TMQ molecule and its dimer in gas phase or through periodic calculation was undertaken with respect to the experimentally measured infrared spectra. The topological features of the bonds were also investigated in conjunction with estimates of net atomic charges to gain insight into the effect of chemical bonding and intermolecular interaction on Li intercalation. Finally, pi-electron delocalization of both quinone and alkali salts of p-semiquinone were determined using the Harmonic Oscillator model of Aromaticity (HOMA) or aromatic fluctuation index (FLU) calculations.

Running (Only) A Single-Point Energy Calculation In Crystal06/09, Proper Input Format For Long-Range Dispersion Contributions In Crystal09, And Removing The MPICH2 Content From The Output File In Pcrystal

Now enjoying the benefits of dispersion-corrected solid-state density functional theory (and a proper MPICH2 implementation for infrared intensity calculations, although this now a problem for reasons to be addressed in an upcoming post) in Crystal09, three issues in recent calculations caused me to think hard enough about keyword formats and job runs that I have opted to post briefly about what to do in case google and bing are your preferred methods of manual searching.

1. How To Run Only A Single-Point Energy Calculation In Crystal06/Crystal09

This had never come up before and, by the time I needed to find an input file to see what do to, the first google search provided Civalleri’s Total Energy Calculation page that currently has broken links to .zip files. There is quite a bit about the different geometry optimization approaches in the manual, but a search for “single-point” provides no information about what to do for only single-point energy calculations.

The solution, it should be obvious after, is simply to not include the geometry optimization section in the input file. What would otherwise be the following (with arbitrary geometry optimization-like info between [COORDINATES] and [BASIS SETS]…




One problem solved by simply not having any optimization parameters (again, makes sense and is now google-able).

2. Proper GRIMME Input Format For Long-Range Dispersion Contributions In Crystal09

This is another example where one’s first efforts in translating the manual into calculations may lead to considerable confusion until the proper format is finally identified (by which time you’ve run many pruned-down input tests).

1.05 20. 25.
1.05 20. 25. s6 (scaling factor) d (steepness) Rcut (cutoff radius)
1  0.14 1.001 Hydrogen Conventional Atomic number , C6 , Rvdw
6  1.75 1.452 Carbon Conventional Atomic number , C6 , Rvdw
7  1.23 1.397 Nitrogen Conventional Atomic number , C6 , Rvdw
8  0.70 1.342 Oxygen Conventional Atomic number , C6 , Rvdw
17 5.07 1.639 Chlorine Conventional Atomic number , C6 ,'Rvdw

I’m not even sure where the final ,’Rvdw comes from. Your .out file may terminate with the following error (or something similar)…

rank 7 in job 8  korterquad_51438   caused collective abort of all ranks
  exit status of rank 7: killed by signal 9

And the ERROR.peN file with any content will show the following, clearly pointing to a GRIMME-specific error…


The problem is the additional content within the manual pages for the GRIMME keyword that require pruning (or, at least, some identifier to show what is and what is not needed). The proper GRIMME section above is properly provided in the INPUT file as…

1.05 20. 25.
1  0.14 1.001
6  1.75 1.452
7  1.23 1.397
8  0.70 1.342
17 5.07 1.639

Where (see page 88 of the Crystal09 manual)…

GRIMME <- keyword is called
1.05 20. 25. <- scaling factor, steepness, cutoff distance
5 <- number of elements in the list (not the total number of atoms)
1  0.14 1.001 <- atomic number, dispersion coefficient, van der Waals radius

When all is properly run, the bottom of your output file will look something like the following:

 CYC  43 ETOT(AU) -5.784662098123E+03 DETOT  1.18E-11 tst  8.17E-15 PX  6.73E-08

 == SCF ENDED - CONVERGENCE ON ENERGY      E(AU) -5.7846620981229E+03 CYCLES  43


 TOTAL ENERGY(DFT)(AU)( 43) -5.7846620981229E+03 DE 1.2E-11 tester 8.2E-15



 SCALE FACTOR (S6):     1.0500

 GRIMME DISPERSION ENERGY (AU) -1.9723347118951E-01
 TOTAL ENERGY + DISP (AU) -5.7848593315941E+03


The Crystal09 manual refers you to Table 1 of the Stefan Grimme paper, “Semiempirical GGA-type density functional constructed with a long-range dispersion correction” (Journal of Computational Chemistry, Volume 27, Issue 15, Pages 1787 – 1799), which I’ve put together into the proper format below. Be sure to (1) delete the elements in parentheses ( -> get rid of the (H) <- ), (2) remove those atoms you do not need, (3) be sure to change the “number of elements” number for your structure, and (4) get and reference the Grimme paper so you have the proper C6 parameters and van der Waals radii accounted for (you’ll be the right nitwit if I mis-copied something and you ran with it (although I trust my input), and you should have the reference regardless).

( H)   1   0.14 1.001
(Li)   3   1.61 0.825
(Na)  11   5.71 1.144
( K)  19  10.80 1.485
(Rb)  37  24.67 1.628
(Be)   4   1.61 1.408
(Mg)  12   5.71 1.364
(Ca)  20  10.80 1.474
(Sr)  38  24.67 1.606
( B)   5   3.13 1.485
(Al)  13  10.79 1.639
(Ga)  31  16.99 1.650
(In)  49  37.32 1.672
( C)   6   1.75 1.452
(Si)  14   9.23 1.716
(Ge)  32  17.10 1.727
(Sn)  50  38.71 1.804
( N)   7   1.23 1.397
( P)  15   7.84 1.705
(As)  33  16.37 1.760
(Sb)  51  38.44 1.881
( O)   8   0.70 1.342
( S)  16   5.57 1.683
(Se)  34  12.64 1.771
(Te)  52  31.74 1.892
( F)   9   0.75 1.287
(Cl)  17   5.07 1.639
(Br)  35  12.47 1.749
( I)  53  31.50 1.892
(He)   2   0.08 1.012
(Ne)  10   0.63 1.243
(Ar)  18   4.61 1.595
(Kr)  36  12.01 1.727
(Xe)  54  29.99 1.881
Y-Cd      24.67 1.639
Sc-Zn     10.80 1.562

Note that the d-block is identical for each row (so no atom numbers provided).

3. Removing The MPICH2 Content From The Output File In Pcrystal(/09)

This final issue does not occur in Pcrystal(/06) but does in Pcrystal(/09), with the reason being (I assume) the new use of MPICH2 in Pcrystal(/09) instead of MPICH in Pcrystal(/06).  The problem comes from running the following set of commands at the terminal window in MPICH2:

mpiexec -machinefile machine -np N /path/to/Pcrystal &>FILENAME.out &

Embedded within the FILENAME.out file will be all flavors of MPI-specific output, perhaps such as the following (in this case errors, but it happens in proper output as well):

application called MPI_Abort(MPI_COMM_WORLD, 1) - process 4
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 7
rank 7 in job 9  korterquad_51438   caused collective abort of all ranks
 exit status of rank 7: return code 1 
rank 4 in job 9  korterquad_51438   caused collective abort of all ranks
 exit status of rank 4: killed by signal 9 


mpiexec_machine (handle_stdin_input 1089): stdin problem; if pgm is run in background...
mpiexec_machine (handle_stdin_input 1090):     e.g.: mpiexec -n 4 a.out < /dev/null &

The solution is to break up the mpiexec output from the Pcrystal output, performed by directing the mpiexec-specific content to, in this case, /dev/null (because it is not necessary except for diagnostic purposes).

mpiexec -machinefile machine -np N /path/to/Pcrystal < /dev/null &>FILENAME.out &

Which removes all traces of mpi-specific output from FILENAME.out.