Something like "JOB ENDED NORMALLY" or "MOPAC DONE"
Closed this issue · 8 comments
I have been using Mopac2016 and have scripts to check when a run is done. It basically looks for a string as suggested in the title. It is also very helpful to know that MOPAC is happy with the result and not just been killed.
Please add a string similar to Mopac2016 so that I know Mopac is done and happy.
Except for some narrowly targeted changes like the header, the output file structure has not changed between MOPAC2016 and the open-source version. All MOPAC calculations should end with an ended normally statement written to stdout, a == MOPAC DONE == footer for the main input file, and END OF MOPAC PROGRAM in the optional .aux output file. If these are missing, then please provide more information about the circumstances when this is happening (e.g. sample input file, computing environment details).
I have the two versions on my OSX 10.12. This is the sequence of commands that show the difference. The first is MOPAC2016 and the second is the conda installed mopac. The output files are generally the same except the final geometry is slightly different and there are some print out changes in the energy section.
NWMoriarty% /Users/NWMoriarty/Desktop/MOPAC2016_for_Macintosh/MOPAC2016.exe test.mop
Wed Oct 26 09:41:11 2022 Job: 'test' started successfully
MOPAC Job: "test.mop" ended normally on Oct 26, 2022, at 09:41.
NWMoriarty% tail test.out
-
* - JOB ENDED NORMALLY *
-
*
TOTAL JOB TIME: 0.49 SECONDS
== MOPAC DONE ==
NWMoriarty% ~/phenix/py3/conda_base/bin/mopac test.mop
Wed Oct 26 09:42:07 2022 Job: 'test' started successfully
MOPAC Job: "test.mop" ended normally on Oct 26, 2022, at 09:42.
NWMoriarty% tail test.out
50 H 0.84394
51 H 0.85079
52 H 0.84939
53 H 0.84821
54 H 0.84747
55 H 0.84117
56 H 0.75339
57 H 0.75381
58 H 0.85775
59 H 0.84539
That is a bug, and it is also rather unusual as the == MOPAC DONE == statement is written to the output file just before the ended normally statement is written to stdout. Something must be causing the output file to close prematurely in an erratic manner.
For reference, the conda-forge version of MOPAC is working just fine with this example on my Mac running OSX 10.15, so I don't have an immediate way of reproducing this problem to debug and fix it. I don't know what differences between our computers might be causing the problem, and I might need to do some less-direct bug hunting to seek out a root cause (e.g. generate a valgrind report for this calculation on a Linux machine to look for possible unallocated memory access problems).
If you have the time, I would be interested to know if a locally compiled version of MOPAC has the same problem on your machine.
I've tried to conda install on a Linux box without success. I will engage the sys admin to see if we can conda install and I'll attempt to compile on my Mac.
Compiling on my OSX was faster than expected but it still does not write to the output. 😞
It looks like std err is being used for the two lines to the terminal. We find that this is fraught so we avoid it. No idea if it's the issue on OSX but you never know.
I will switch that output from stderr to stdout, but I doubt that will fix this issue.
If you have MOPAC compiling, it might help me to debug the problem if you capture and print error flags from the write statement on line 1029 of src/run_mopac.F90. Presumably Fortran can provide a valid reason for the failure of the write statement.
Apologies, this was my calling code partially overwriting the log file. All is well now.