QMTP failed for no known reason

[faribas]

A job with QMTP suddenly ended like this:

Created new species: C10H11O6J(11657)
Created new forwards 1,3_Insertion_ROR reaction: C4H3O2J(10201) + C6H8O4(120) --> C10H11O6J(11657)
Pre-existing successful quantum result for QRILEPLAKMWFGL-UHFFFAOYAN (InChI=1/C10H12O6/c11-3-1-2-8(12)15-6-4-9-14-5-7(16-9)10(6)13/h3-4,7,9-10,13H,1-2,5H2) has been found. This log file will be used. *Note that input file was read to confirm lack of InChIKey collision (InChI probably more than 79 characters)
Point group: C1
Thermo for QRILEPLAKMWFGL-UHFFFAOYAN: -216.54   132.27  57.39   73.66   87.48   98.62   114.92  126.07  142.12  
HBI-based thermo for ROTVKXHJHGBFDJ-UHFFFAOYAC(InChI=1/C10H11O6/c11-3-1-2-8(12)15-6-4-9-14-5-7(16-9)10(6)13/h1,3-4,7,9-10,13H,2,5H2): -176.74   129.9   56.03   72.09   85.75   96.73   112.26  122.96  138.62  
Pre-existing successful quantum result for HWIKTQVFQRVNSX-UHFFFAOYAF (InChI=1/C10H12O6/c11-3-1-2-8(12)15-6-4-9-14-5-7(16-9)10(6)13/h1,3-4,7,9-11,13H,2,5H2) has been found. This log file will be used. *Note that input file was read to confirm lack of InChIKey collision (InChI probably more than 79 characters)
Point group: C1
Thermo for HWIKTQVFQRVNSX-UHFFFAOYAF: -202.92   132.09  58.82   74.85   88.42   99.34   115.27  126.16  141.94  
HBI-based thermo for ROTVKXHJHGBFDJ-UHFFFAOYAC(InChI=1/C10H11O6/c11-3-1-2-8(12)15-6-4-9-14-5-7(16-9)10(6)13/h1,3-4,7,9-10,13H,2,5H2): -167.02   130.98  57.48   72.86   85.94   96.55   112.14  122.83  138.15  
Created new species: C10H11O6J(11658)
Created new forwards 1,3_Insertion_ROR reaction: C4H3O2J(10201) + C6H8O4(120) --> C10H11O6J(11658)
CRITICAL: An InChI was not found in file: KGSQYNLLNWNTSQ-UHFFFAOYAJ.log

The job suddenly stopped with no helpful debugging messages. Both KGSQYNLLNWNTSQ-UHFFFAOYAJ.log and KGSQYNLLNWNTSQ-UHFFFAOYAJ.gjf are empty.

There is no record of species 11658 in the saved dictionary or restart files, so we don't know what it was. However, it looks like it is made by the reaction of

C4H3O2J(10201)
1  C 0 {5,D} {2,S} {7,S}
2  C 0 {1,S} {3,D} {8,S}
3  C 0 {2,D} {4,S} {9,S}
4  C 1 {3,S} {6,D}
5  O 0 {1,D}
6  O 0 {4,D}
7  H 0 {1,S}
8  H 0 {2,S}
9  H 0 {3,S}

and

C6H8O4(120)
1  C 0 {2,S} {6,S} {7,S} {11,S}
2  C 0 {1,S} {3,S} {9,S} {12,S}
3  C 0 {2,S} {4,D} {10,S}
4  C 0 {3,D} {5,S} {13,S}
5  C 0 {4,S} {7,S} {8,S} {14,S}
6  C 0 {1,S} {8,S} {15,S} {16,S}
7  O 0 {1,S} {5,S}
8  O 0 {5,S} {6,S}
9  O 0 {2,S} {17,S}
10  O 0 {3,S} {18,S}
11  H 0 {1,S}
12  H 0 {2,S}
13  H 0 {4,S}
14  H 0 {5,S}
15  H 0 {6,S}
16  H 0 {6,S}
17  H 0 {9,S}
18  H 0 {10,S}

So it is probably the product of reaction 35, 36, 44, 45, 46 or 47 of these:

http://rmg.mit.edu/database/kinetics/results/reactant1=1%20C%200%20%7B5,D%7D%20%7B2,S%7D%20%7B7,S%7D%20;2%20C%200%20%7B1,S%7D%20%7B3,D%7D%20%7B8,S%7D%20;3%20C%200%20%7B2,D%7D%20%7B4,S%7D%20%7B9,S%7D%20;4%20C%201%20%7B3,S%7D%20%7B6,D%7D%20;5%20O%200%20%7B1,D%7D%20;6%20O%200%20%7B4,D%7D%20;7%20H%200%20%7B1,S%7D%20;8%20H%200%20%7B2,S%7D%20;9%20H%200%20%7B3,S%7D__reactant2=1%20C%200%20%7B2,S%7D%20%7B6,S%7D%20%7B7,S%7D%20%7B11,S%7D%20;2%20C%200%20%7B1,S%7D%20%7B3,S%7D%20%7B9,S%7D%20%7B12,S%7D%20;3%20C%200%20%7B2,S%7D%20%7B4,D%7D%20%7B10,S%7D%20;4%20C%200%20%7B3,D%7D%20%7B5,S%7D%20%7B13,S%7D%20;5%20C%200%20%7B4,S%7D%20%7B7,S%7D%20%7B8,S%7D%20%7B14,S%7D%20;6%20C%200%20%7B1,S%7D%20%7B8,S%7D%20%7B15,S%7D%20%7B16,S%7D%20;7%20O%200%20%7B1,S%7D%20%7B5,S%7D%20;8%20O%200%20%7B5,S%7D%20%7B6,S%7D%20;9%20O%200%20%7B2,S%7D%20%7B17,S%7D%20;10%20O%200%20%7B3,S%7D%20%7B18,S%7D%20;11%20H%200%20%7B1,S%7D%20;12%20H%200%20%7B2,S%7D%20;13%20H%200%20%7B4,S%7D%20;14%20H%200%20%7B5,S%7D%20;15%20H%200%20%7B6,S%7D%20;16%20H%200%20%7B6,S%7D%20;17%20H%200%20%7B9,S%7D%20;18%20H%200%20%7B10,S%7D

[nickvandewiele]

I am aware of this problem specific to running QMTP with gaussian03. Nate showed me similar findings. We are, however, not sure whether this is a bug in RMG-Java or elsewhere related to g03.

Remark 1: Was this run on Pharos through the scheduler? If yes, be aware that some nodes do not have g03 installed. if the scheduler assigns the RMG job to a g03-less node, then it obviously can't work. this also meant that other molecules had thermochemistry already stored in the QMfiles folder, which is likely if you tried to run the same job already before.

Remarkt 2: as Greg pointed out in his Ph.D thesis, the majority of the QMTP calculations (> 90%) are successfully finished using MOPAC with the first couple of attempts (and the UFF structure). This implies that setting the QMTP flag to "both" (first use Mopac, then gaussian if fail) is the best strategy if you like the PM3 level of theory. On top of that, my understanding is that mopac also runs faster than g03.

[rwest]

Thanks @nickvandewiele. This was run on a NU computer, and the first few hundred species ran fine.

With the error you have seen before, would you expect the .gjf file to be empty? It is no wonder to me that the .log file is empty if the gaussian input is also empty. This would suggest to me a problem with RMG/OpenBabel/RDKit/InChI rather than g03.

@faribas I suggest you try to get it working with MOPAC and set the QMTP flag to "both" as Nick suggests.

[nyee]

I'd like to add that I actually encountered this problem when running the QMTP on "both", but resolved it when I used "mopac" only.

If you specify both RMG will try mopac first then Gaussian if it fails. The problem is you may still run into the same error in this case.

If you specify 'mopac' it will try mopac first then default to the Benson if it fails. You won't get a QM calculation for the species in question, but at least the job will keep running.