Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Format of the forces in extXYZ output file. #274

Closed
AugustinLu opened this issue Oct 4, 2023 · 7 comments
Closed

Format of the forces in extXYZ output file. #274

AugustinLu opened this issue Oct 4, 2023 · 7 comments
Labels
improves: output Making output clearer or more consistent
Milestone

Comments

@AugustinLu
Copy link
Contributor

In some cases, for high values of the forces, the space allocated for writing them into an extXYZ file is insufficient and leads to unusable data, as shown below, where $F_x$ cannot be written properly:
image

Cause
In io_module.f90, lines 2937-2938

write(lun,'(a4,6f16.8)') atom_name, atom_coord(:,i)*dist_conv_loc, &
                (for_conv_loc*atom_force(j,i), j = 1, 3)

f16.8 numbers can be insufficient for some specific cases (ex: calculaling the forces between two atoms at short distance)

Proposed solution

write(lun,'(a4,3f16.8,3e16.8)') atom_name, atom_coord(:,i)*dist_conv_loc, &
                (for_conv_loc*atom_force(j,i), j = 1, 3)

Use e16.8 instead of f16.8 to output the forces.

Does this sound reasonable?

@AugustinLu AugustinLu added the improves: output Making output clearer or more consistent label Oct 4, 2023
@JianboLin
Copy link
Contributor

Thank you for your checking and suggestion.
And sorry for my delayed response.

Your proposed solution is also quite reasonable to me.
How about the following?
'(a4,6(x,f0.8))'

It will keep float format and slightly save some disk space.

@davidbowler
Copy link
Contributor

I wonder whether we really need eight decimal places in both of these outputs; if we reduced to (say) 4 dp for positions and 4 or 5 dp for forces (given that our convergence criterion is often around 1e-4 Ha/Bohr) that would allow output to be smaller.

@davidbowler davidbowler added this to the Release v1.4 milestone Jan 16, 2024
@tsuyoshi38
Copy link
Contributor

I wonder whether we really need eight decimal places in both of these outputs; if we reduced to (say) 4 dp for positions and 4 or 5 dp for forces (given that our convergence criterion is often around 1e-4 Ha/Bohr) that would allow output to be smaller.

We often want to use this file to generate machine-learning force fields (ML-FF), as training data. In such cases, it is safe to have more digits.
This file is also used to check the trajectory of MDs by using ML-FF. If we are not careful to generate ML-FF, forces can be very large as Augustin mentioned.

@davidbowler
Copy link
Contributor

Thank you @tsuyoshi38 for clarifying. Do you need significant figures or decimal places for the ML-FF? I'm concerned that if we use the e16.8 format then we will truncate the absolute precision (if the forces have magnitude around 10,000, for instance, then using e16.8 will mean that you only get the forces to 1e-4 or so). I think that both solutions proposed above could work - please choose whichever suits your needs best and implement it.

@tsuyoshi38
Copy link
Contributor

Thank you @davidbowler for the comment.

Do you need significant figures or decimal places for the ML-FF?
We may not need such long decimal places, but it is just safe for now.
(Actually, I know that the calculated DFT forces do not have such accuracy due to the SCF tolerance etc., but ...)

I'm concerned that if we use the e16.8 format then we will truncate the absolute precision (if the forces have magnitude around 10,000, for instance, then using e16.8 will mean that you only get the forces to 1e-4 or so).

I don't think we need high precision when the forces are huge. It appears only in the MD simulations using inappropriate ML-FF, and we just want to know how large the forces are in such cases.

I think that both solutions proposed above could work - please choose whichever suits your needs best and implement it.

Thank you. I had a discussion with Augustin and Lin-san, and we agreed that we want to go with "e16.8" for now.

@AugustinLu
Copy link
Contributor Author

Thank you @tsuyoshi38 and @davidbowler for your comments.

Should I issue a pull request to the develop branch?

@davidbowler
Copy link
Contributor

Closed by #309

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improves: output Making output clearer or more consistent
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

4 participants