Issues with loss functions and energy and forces keys

[neubifx]

Thank you for the amazing tool! I've been attempting to train models using datasets I generated, but I'm encountering issues with zero loss functions over epochs and exceptionally high RMSE values. As an example, when attempting to reproduce the example provided in the documentation using the 3BPA dataset, I had the following log file:

MACE_model_run-123.log

This behavior persists for me across other examples and tutorials I have tested.

I have observed that regardless of the keys I assume for forces_key and energy_key, the energies and forces aren't being computed. I am unsure about what might be causing this issue.

Thank you in advance for any assistance, and I apologize if I am missing an obvious step!

[neubifx]

Hi,

I took a closer look at how data is extracted in scripts_utils.py and, after some testing, I discovered that the keys in the extended XYZ format were not being read correctly in ASE version ase-3.23.0b1, which I was using due to some implementations specific to that version. I reverted back to ase-3.22.1, and now the data is being extracted correctly from the XYZ files. Consequently, I no longer have issues during training.

[ilyes319]

Hey @neubifx, thank you for letting us now. I hope ASE will fix it in the official release.

[bernstei]

I doubt it: see https://gitlab.com/ase/ase/-/merge_requests/3257 and linked issues

@ilyes319 I think you should just stop supporting (or at least defaulting to) plain energy/forces/etc keys for fitting quantities. Their use also leads to other issues, like calculating the MLIP quantities on fitting configs resulting in accidentally overwriting the DFT quantities.

[ilyes319]

I remember you mentioned that issue before. What's the alternative? Should we always ask for non-standard input keys?

[bernstei]

Should we always ask for non-standard input keys?

That's my opinion, yes. Definitely in practice, because I really don't see Ask budging on what ASE does with "default" key names (namely putting them in a atoms.calc = SinglePointCalculator and not in Atoms.info and Atoms.arrays). But even for more principled reasons: we've already had an issue when someone loaded in reference configs and ran some MACE calculations on them, thereby accidentally overwriting the true reference energies (I can't remember if that was a github issue or a slack post, but it happened to someone).

I know it'll break a lot of people's existing setups, which is bad, but I don't see a better way for the longer term future.

[bernstei]

Also, conceptually, these quantities don't "belong" to a configuration - they belong to a combination of a configuration and a particular calculator. Leaving them complete generic obscures that.

[gabor1]

Let's make the key names in the mace training script mandatory. This will help bring the issue to the fore. And all our sample scripts and tutorials should use custom key names.

Gábor Csányi Professor of Molecular Modelling Engineering Laboratory, University of Cambridge Pembroke College Cambridge

Pembroke College supports CARA. A Lifeline to Academics at Risk. http://www.cara.ngo/

On 1 Apr 2024, at 14:03, bernstei @.***> wrote:



Also, conceptually, these quantities don't "belong" to a configuration - they belong to a combination of a configuration and a particular calculator. Leaving them complete generic obscures that.

— Reply to this email directly, view it on GitHubhttps://github.com/ACEsuit/mace/issues/364#issuecomment-2030262127, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABIANZ4ECVCKV5C6HK4HQUTY3GONLAVCNFSM6AAAAABFPUQZLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZQGI3DEMJSG4. You are receiving this because you are subscribed to this thread.Message ID: @.***>