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

Simulation unstable when using triclinic updates in MTTK integrators #755

Open
rashidrafeek opened this issue Oct 15, 2024 · 7 comments
Open

Comments

@rashidrafeek
Copy link

I was testing out some simulations with GPUMD and I noticed that the when using the tri option in the npt_mttk ensemble, the atoms breaks apart. This only occurs for the tri option and not the iso or aniso options to update cell vectors. I initially noticed this for a model I had trained, but I also tested this with one of the models in nep-data gilab repo. I specifically used the model for CsPbBr3 there and the same model.xyz there, with the following input:

potential      nep.txt

# The equilibration stage
ensemble npt_mttk temp 0.10 0.10 tri 0 0
time_step    1
#每10000步输出一个数据
dump_thermo 100
dump_position 100
run 10000

The cell parameter changes indicating large volume change in the simulation is shown below:
cell_plot_tri
For comparison, the following is obtained when I use aniso instead of tri:
cell_plot_aniso

@brucefan1983
Copy link
Owner

I guess it is becaue the MTTK barostat is not very stable.

So you want to control all the 6 degrees of freedom. In this case you can try to use the more stable Berendsen or SCR method. For example, using the SCR method, you can write

ensemble npt_scr 0.10 0.10 100 0 0 0 0 0 0 100 100 100 100 100 100 1000

Also, it is a good practice to write velocity in the beginning to set up the initial temperature. In your example where the target temperatue is 0.1, it is better to add

velocity 0.1

With the above considerations, you will have:

potential      nep.txt
velocity 0.1

# The equilibration stage
ensemble npt_scr 0.10 0.10 100 0 0 0 0 0 0 100 100 100 100 100 100 1000
time_step    1
#每10000步输出一个数据
dump_thermo 100
dump_position 100
run 10000

@rashidrafeek
Copy link
Author

Thanks for the suggestion. Yes, I am currently using the SCR barostat which seems to be working fine. I had some previously done simulations with LAMMPS which uses the MTTK barostat, which is why I tried this. Also, I was thinking the MTTK integrator is supposed to sample NPT ensemble more reliably. But it seems the SCR barostat is also fine? I am unsure of what differences I should expect. Thanks anyways.

The reason I posted this as an issue is because it seems that this issue arises very fast (within 100 timesteps), so I thought it might be due to some implementation issue. Also, it seemed that the MTTK barostat with the tri option was working fine for a different system in LAMMPS (but using a DeepMD potential). But when I trained an NEP model for that system it was leading to the above issue in GPUMD (only with the tri option).

@brucefan1983
Copy link
Owner

  • SCR can sample the NPT ensemble properly according to this paper: 10.1063/5.0020514

  • It could well be that the implementation of the tri option for MTTK in GPUMD has problems. Could you check if your NEP model can run properly in LAMMPS with the tri option? Here is the LAMMPS interface for NEP in case you have not seen it yet: https://github.com/brucefan1983/NEP_CPU

@rashidrafeek
Copy link
Author

Oh I didn't know there was a LAMMPS implementation. Thanks for the info. I will try compiling that when I get time and will report the results here.

I will use the SCR barostat for my NEP simulations. Thanks for the pointer.

@psn417
Copy link
Collaborator

psn417 commented Oct 28, 2024

Due to certain limitations of GPUMD code, we cannot change an orthogonal box to a tri box during a simulation. If you want to use tri MTTK, you need to change the box to tri before simulation. For example, you can add 0.0001 to an non-diagonal element in model.xyz to make it beome tri.

@rashidrafeek
Copy link
Author

Thanks. This was indeed the issue and it got solved by starting from an initial triclinic cell. It would be nice to give a warning in this case, where the cell is orthogonal and the required simulation requires a tri box. Otherwise, feel free to close the issue.

@brucefan1983
Copy link
Owner

Thanks for your explanation @psn417

@rashidrafeek I will leave it here for some time. Perhaps we can make this part more robust soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants