[ase-users] Issue with NPT calculation resets in ASE

[Harry Thomas]

Hi,

In case it's of use to anyone, I thought I would just detail the short-term solution here. The issue was that the strain rate (eta) was not being saved at the end of the calculation, meaning when the calculation is restarted, the strain rate is reinitialized as a 3x3 matrix of zero values.

Saving the strain rate in an external file format (ie: numpy file) at the end of a calculation and reloading at the start of a new calculation fixed the issue I was having.

Also, thanks for all the replies in this thread. They really helped solve the issue.

Kind regards, Harry.
________________________________
From: Harry Thomas <ThomasHN2 at cardiff.ac.uk>
Sent: 30 March 2022 16:18
To: ase-users at listserv.fysik.dtu.dk <ase-users at listserv.fysik.dtu.dk>
Subject: Re: [ase-users] Issue with NPT calculation resets in ASE

Hi,

Thank you very much for the replies, they are really helpful.

Would it be appropriate then to open this (changing the trajectory dynamics classes to allow the storage of such data) as a gitlab issue then?
Or would you say this isn't necessary and it is more appropriate in general to store that kind of data (ie: the momentum-like variables) externally in other file formats?

Kind regards, Harry.
________________________________
From: ase-users <ase-users-bounces at listserv.fysik.dtu.dk> on behalf of Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via ase-users <ase-users at listserv.fysik.dtu.dk>
Sent: 30 March 2022 13:24
To: ase-users at listserv.fysik.dtu.dk <ase-users at listserv.fysik.dtu.dk>
Subject: Re: [ase-users] Issue with NPT calculation resets in ASE

External email to Cardiff University - Take care when replying/opening attachments or links.
Nid ebost mewnol o Brifysgol Caerdydd yw hwn - Cymerwch ofal wrth ateb/agor atodiadau neu ddolenni.


On Mar 30, 2022, at 4:27 AM, Jakob Schiøtz via ase-users <ase-users at listserv.fysik.dtu.dk<mailto:ase-users at listserv.fysik.dtu.dk>> wrote:

I guess one should implement some way of storing this kind of additional information in the trajectory file - or a way to extract it from the dynamics, and save it for the restart.  I guess it could be done manually by looking at the source code, and figuring out which attributes of the dynamics that should be saved.

I get the sense that it isn't the ASE way (a more strict object oriented approach seems to be preferred), but that's exactly why I like storing such quantities in the `Atoms.info<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fatoms.info%2F&data=04%7C01%7CThomasHN2%40cardiff.ac.uk%7Cd1d2745a78f54763b2ac08da1248b925%7Cbdb74b3095684856bdbf06759778fcbc%7C1%7C0%7C637842400796943095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vFvkb2LPPt1Lx%2B2dOXZVCE%2Bt9jUDsSPzolpNZ0BRCJg%3D&reserved=0>` or `Atoms.arrays`, and using file formats that can handle such arbitrary data (which is why `extxyz` is designed that way). It simplifies arbitrary things that use `Atoms` (like trajectories), because they don't have to have a complex object oriented inheritance structure with `Atoms` to load and save their own associated data. If you want to stick to a stricter object oriented approach, classes that related to trajectory dynamics need to extend the writing methods to save and load their own data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.fysik.dtu.dk/pipermail/ase-users/attachments/20220426/7eaca6a1/attachment.htm>