OrderN / CONQUEST-release

Full public release of large scale and linear scaling DFT code CONQUEST
http://www.order-n.org/
MIT License
96 stars 25 forks source link

Format of the forces in extXYZ output file. #274

Closed AugustinLu closed 3 months ago

AugustinLu commented 7 months ago

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?

JianboLin commented 4 months ago

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 commented 4 months ago

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.

tsuyoshi38 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

Thank you @tsuyoshi38 and @davidbowler for your comments.

Should I issue a pull request to the develop branch?

davidbowler commented 3 months ago

Closed by #309