Closed paulsaxe closed 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.
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.
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.
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:
Similar code is used when writing the gradients each iteration, e.g.
GRADIENTS_UPDATED:KCAL/MOL/ANGSTROM
. Search forfmtnnp4
will show all instances.To Reproduce This input writes GRADIENTS to the AUX file:
while this does not:
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