I would like to ask what settings might have an effect on restart problems that I have encountered with several GFN-FF simulations (a sample restart file is attached):
if using the restart file with default settings, extremely high temperature error is produced although the previous simulation did not indicate that (the energies match)
if using the restart file wihout absolute coordinates and velocities, the initial energy does not match the energy of final energy from the previous simulation.
Best regards,
Hi Osvalds,
If you can post your original input/output that would help since checking restarting needs both the original and restart file. If you can provide these then I’ll take a look.
Thanks,
Julian
please find the input and restart files (these are from another simulation) uploaded. I would like to add the first error (high temperature) was fixed by not changing the lines that start with ‘aver’ and ‘current_time’.
Best regards,
Hi Osvalds,
Thanks for providing the files, though since the system size is large this could take some time to run. If you alter the restart file (other than extending the time of the simulation) then it could be that you mess something up such that things won’t restart correctly & you end up with the a high temperature or different energy. So the first question is to check whether you get the right energy if you just run with the restart file without modifying it?
Best regards,
Julian
if I restart the simulation without changing anything then I do get the same energy. However, by only removing the absolute coordinates from the restart file or (equivalently) performing a single point calculation based on the wrapped coordinates only I would get a different energy value (my main concern). This could imply that the potential energy is dependent on trajectory, which should not be, and the energies of related systems could not be compared in a unique way.
Best regards,
Hi Osvalds
There are two points to discuss in your observations:
Using the wrapped coordinates to do a single point energy only will potentially give a different energy for GFN-FF. This is because the connectivity and potential parameters are defined by the initial geometry in a run & so if the first geometry is different then the energy could also be potentially different. This is why GULP passes the original geometry to the restart file for GFN-FF so that it can regenerate the parameters correctly. If this is removed then your energy will not be guaranteed to be the same.
Removing the absolute coordinates while leaving everything else the same (including the GFN-FF restart information) in principle should give the same energy. However, because of the complexity of restarting GFN-FF I suspect that there is an issue relating to the coordinates vs the GFN-FF restart coordinates. It could be that if both are wrapped consistently then the energy should work. This is something that could be looked into.
Bottom line is that it needs a lot of care to alter GFN-FF restart files to keep things consistent as it’s a complex force field.
Regards,
Julian
for clarity, I would like to add in the particular cases I did not remove the first geometry coordinates, so that any change in energy, if applicable, would be solely due to the presence of absence of absolute coordinates.
Best regards,
PS: additionally, I would like to mention a potentially related case:
if I change the simulation mode of a restart file from ‘md’ to ‘single’ or ‘optimise’ then I may also get substantially different starting energies (please find the initial input and restart files uploaded):
Hi Osvalds,
Apologies for the delay - I’ve now had time to look into this and check what is happening.
The important principle is that GFN-FF requires the use of the absolute coordinates without wrapping over period boundaries. This is because of the need to keep track of bonds, etc. For most runs this was being handled correctly in GULP since the “nomod” keyword was implicitly applied if GFN-FF is being used & so there were no issues. In the case of molecular dynamics the coordinates are wrapped back into the main cell in one set of coordinates, while the absolute values are also kept as well. This is because MD needs to know the absolute positions to evaluate diffusion etc.
Now we come to the restarting. If restarting MD then everything is still fine because the absolute coordinates can be read and used from the MD restart info. If restarting an optimisation everything will be fine because the “nomod” keyword will have been applied. The problem is when you switch from one mode to the other & things go wrong. If you copy the “absolute_coord” section to be the coordinates in “cartesian” in your test example then everything should work fine.
To resolve this I’ve now applied the “nomod” keyword to MD as well so that the default coordinates should allow restarting of MD in other modes for GFN-FF (as would work for other potentials already). This change will take effect when I’m able to put a new version of the code up on the web. In the meantime I’ll email you the fixed subroutine that makes the change so that you can update your code.
Regards
Julian