openmopac / mopac

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

Gradients not written to AUX file if smaller than 10^-4 #205

Closed paulsaxe closed 2 months ago

paulsaxe commented 2 months ago

Describe the bug The gradients are not written to the AUX file if they are smaller than 1.0e-04. The code in to_screen.F90 is this:

      sum = 0.d0
      do i = 1, nvar
        if (abs(grad(i)) > sum) sum = abs(grad(i))
      end do
      if (sum > 1.d-4) then
        write(hook,"(a,i"//paras//",a)")" GRADIENTS:KCAL/MOL/ANGSTROM[",nvar, "]="
        read(fmt9p4,'(3x,i2)')i
        j = max(int(log10(sum)),1)
        write(fmtnnp4,"(i2.2,'.',i2.2)")4 + j + i, i
        write(hook,"(10f"//fmtnnp4//")") (grad(i), i=1,nvar)
      end if
    end if

Similar code is used when writing the gradients each iteration, e.g. GRADIENTS_UPDATED:KCAL/MOL/ANGSTROM. Search for fmtnnp4 will show all instances.

To Reproduce This input writes GRADIENTS to the AUX file:

1SCF PM6-ORG GRADIENTS BONDS AUX(MOS=10,XP,XS,PRECISION=3) CHARGE=0 SINGLET
NEB
product
H    0.35894828 1   0.00000000 1  -0.00000000 1
H   -0.35894828 1   0.00000000 1   0.00000000 1

while this does not:

1SCF PM6-ORG GRADIENTS BONDS AUX(MOS=10,XP,XS,PRECISION=3) CHARGE=0 SINGLET
NEB
product
H    0.35894772 1   0.00000000 1  -0.00000000 1
H   -0.35894772 1   0.00000000 1   0.00000000 1

Expected behavior This causes problems for codes that use the data in the AUX file. For example, using 1SCF GRADIENTS may or may not write the gradients to the AUX file, depending on whether the structure is well minimized or not. A code reading the AUX file cannot rely on the GRADIENTS being in the file, which is awkward and difficult to handle. I believe that zeroes should be written or a format such as D used. Operating system MacOS

godotalgorithm commented 2 months ago

This seems to have been an effort to reduce the amount of "trivial" information in the AUX file. However, as you are experiencing, it makes reading the AUX file more complicated because a parser needs to know that the absence of the GRADIENTS block implies very small gradients. I will remove the conditionality of this output right away in the development version.

I'm hesitant to change the formatting of real numbers in the AUX file because some of the AUX-based MOPAC interfaces seem to be very fragile from my experiences in servicing support requests. The soon-to-be-released diskless API provides information like gradients as raw real-number outputs without any loss of precision, so that should become the preferred interface if loss of precision is a concern.

godotalgorithm commented 2 months ago

As noted in the PR itself, the printing of gradients (and several other properties) in the AUX file is still conditional, but the condition is now that all gradient components are strictly zero. This is needed to prevents uncomputed gradients from being printed right now. Ideally, MOPAC will eventually have a logical layer clarifying which properties have been computed to replace these zero tests, but that simply doesn't exist in the code right now. The probability of all computed gradients being numerically zero is astronomically low, and it might not even be an achievable condition from my experiences in numerical root finding. If you can create a test that produces numerically zero gradients, then I'll consider implementing a first version of such a logical layer.

paulsaxe commented 2 months ago

Well, that was more complicated than expected. I think the fix is fine: I can’t imagine calculating all exact zeroes. Let’s cross that bridge when we come to it. Thanks!

Paul

On Aug 13, 2024, at 4:54 PM, Jonathan E. Moussa @.***> wrote:

As noted in the PR itself, the printing of gradients (and several other properties) in the AUX file is still conditional, but the condition is now that all gradient components are strictly zero. This is needed to prevents uncomputed gradients from being printed right now. Ideally, MOPAC will eventually have a logical layer clarifying which properties have been computed to replace these zero tests, but that simply doesn't exist in the code right now. The probability of all computed gradients being numerically zero is astronomically low, and it might not even be an achievable condition from my experiences in numerical root finding. If you can create a test that produces numerically zero gradients, then I'll consider implementing a first version of such a logical layer.

— Reply to this email directly, view it on GitHub https://github.com/openmopac/mopac/issues/205#issuecomment-2287120575, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFRFRRDHK57PRNBR3IUN5TDZRJXAVAVCNFSM6AAAAABMCG4MVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBXGEZDANJXGU. You are receiving this because you authored the thread.