Open HanmeiTang opened 6 years ago
Yes, pls make this happen. It is overdue.
All - any update on this issue?
Sorry being late, I will migrate the code shortly.
@HanmeiTang any update on this issue?
Sorry being late, I was busy with my qualification exam. I will work on this issue this week.
Can we add a flag for SSNEB too (VTST) ?
Oh, sure. I am not very familiar with G-ssNEB, so for now I use the suggestions from this discussion (link) to set up input set (VTST only).
Basic settings
ISIF = 3
IBRION = 3
POTIM = 0.05
ICHAIN = 0
LNEBCELL = False (Turn off SSNEB, which is the default)
IMAGES = 5 (Use fewer images, usually 5 images)
IOPT (IOPT must not be set)
Possible solutions to unconvergence:
ENCUT
>= 1.3*ENMAX
.I am running a few G-ssNEB calculations for testing. As a first step, I will add this tag to pymatgen_diffusion.neb.io.MVLCINEBSet
. Will get back to you once the tests are done.
Pls defer the G-ssNEB. Just get the current workflow done in a robust manner. Anyone who wants G-ssNEB is welcome to implement a robust set of rules after benchmarking. I don't want us to blindly implement something without benchmarking.
My request for SS-NEB was literally just to add a kwarg (to save the user having to use an incar_powerup to set LNEBCELL), but fine to leave it out if it requires further work.
Since the CI workflows require VASP with VTST compiled in can we make this clear in the docstring too. Other docstring improvements would be welcome, it wasn't clear to me how to set e.g. the number of images (it looks like you set this by changing the length of user_incar_settings
, does [{}, {}, {}]
== 3 images?). I don't use NEB often so this was a little confusing to me.
@HanmeiTang Improve the doc so that it is clear. Just leave SS-NEB for now.
Hi all! I'm not sure if anyone is still actively working on this issue. But for my own work it would be helpful to have a straight forward NEB workflow so I wanted to offer contributing something along these lines:
Basic NEB Workflow:
NEB Workflow:
The basic NEB Workflow would be intended for the most simple NEB use case. The other NEB Workflow would be a base for more easily implementing the numerous variations of NEB (the user can use whatever interpolation scheme they'd like since images are provided as inputs, customize the input vasp parameters for finer convergence criteria, setting INCAR flags for climbing image, etc.) I'm inclined to have these written to only be compatible with VASP compiled with VTST (since it seems this has become the common standard over running with VASP without VTST).
Some gaps that I would not be tackling that I want to acknowledge...
I think if these two workflows were added, it would provide a good starting point/foundation for other future additions. Please let me know if working on this might cause problems for anyone else, or if there is any other feedback to consider!
hi @acrutt
I'd be supportive of a more basic NEB workflow but unfortunately I don't think I'd be able to help out much.
One comment not explicitly mentioned in your message would be to try to make it easy to use a different interpolation scheme than linear if a user has one. My guess is that one of the major requests on the workflow, were it to be written, would be to support non-linear interpolations.
I agree enabling additional interpolation schemes would be a good future addition! For now I didn't want to get into that use case because there can be a variety of other additional inputs or calculations needed depending on the interpolation scheme (e.g. charge density for the pymatgen pathfinder method, I saw mention of IDPP in the current workflow but I'm unfamiliar with that interpolation scheme, etc). I'm hoping that additional functionality can be built in more easily from the foundation of the 2nd NEB workflow described (which takes a list of images as its input).
Current NEB workflow can be improved for the following aspects:
toDB
firetask;Some of the above bulletins have been mentioned in the previous discussion and I and Iek-Heng @johnson1228 would like to implement the above modification. Since the real NEB tests usually need additional queueing time, I would like to estimate this issue to be done in one month.