Richard West

Do you have a solution to this Nick? Push it to your fork and we'll check it out.

Here's the longer output (curtailed at 10 samples): Self counts: java.net.PlainSocketImpl.socketAccept 159333 37.8% java.lang.UNIXProcess.waitForProcessExit 95934 22.8% java.io.FileInputStream.readBytes 95847 22.7% java.util.LinkedList.clone 34920 8.3% jing.rxn.Structure.equals 7288 1.7% java.lang.Object.wait 7094 1.7% java.lang.UNIXProcess.forkAndExec 6929...

I mean that it spends a large majority of the CPU time, not generating reaction mechanisms, but checking that the reaction systems that have been converged for the last 100...

Another possible difference: I had 32 reaction systems (this is partly why it spent a long time simulating them)

I think 8937668936186858b7e89f3b1c21e1802d000da5 is a step in the right direction. Perhaps @gmagoon can comment further (perhaps also in the documentation) what the recommended approach is?

Here are the input files to two jobs that have been frozen in l103.exe for ~15 hours now. Notice they are the same molecule. rwest@node47:/tmp/60336.1.long2/QMfiles$ cat ASIRPOSRZLOBKS-UHFFFAOYAJ.gjf %chk=/tmp/60336.1.long2/QMfiles/RMGrunCHKfile.chk %mem=6MW %nproc=1...

Turns out that these messages were from before commit 6d312b69e63551b742b6e2af855510e6690b97a6 so perhaps it does help after all. I'll try again and see if things are any better.

This could be intentional - perhaps the top level node is better (or at least safer) guess than the result of a crazy average. I would carefully check the consequences...

I certainly wouldn't have guessed that preventing averaging at the top level node prevents _all_ averaging for that family. At least not without thinking hard.

Perhaps see http://github.com/gmagoon/RMG-Java/commit/f652decc547d0a5107435d9bc4ca64d11a9bbe7c