openmopac / mopac

Molecular Orbital PACkage
http://openmopac.net
GNU Lesser General Public License v3.0
122 stars 32 forks source link

Something like "JOB ENDED NORMALLY" or "MOPAC DONE" #128

Closed nwmoriarty closed 1 year ago

nwmoriarty commented 1 year ago

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.

godotalgorithm commented 1 year ago

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).

nwmoriarty commented 1 year ago

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

godotalgorithm commented 1 year ago

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.

nwmoriarty commented 1 year ago

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.

nwmoriarty commented 1 year ago

Compiling on my OSX was faster than expected but it still does not write to the output. 😞

nwmoriarty commented 1 year ago

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.

godotalgorithm commented 1 year ago

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.

nwmoriarty commented 1 year ago

Apologies, this was my calling code partially overwriting the log file. All is well now.