Optimized NEB workflow

[HanmeiTang]

Current NEB workflow can be improved for the following aspects:

1. Reduce the complexity of the workflow and make it more consistent with other existing workflows;
2. add toDB firetask;
3. Unittest for all firetasks;
4. add examples and optimize document.
5. simplify config yaml file (optional)

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.

[shyuep]

Yes, pls make this happen. It is overdue.

[computron]

All - any update on this issue?

[HanmeiTang]

Sorry being late, I will migrate the code shortly.

[computron]

@HanmeiTang any update on this issue?

[HanmeiTang]

Sorry being late, I was busy with my qualification exam. I will work on this issue this week.

[mkhorton]

Can we add a flag for SSNEB too (VTST) ?

[HanmeiTang]

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).

1. 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)

2. Possible solutions to unconvergence:

   1. ENCUT >= 1.3*ENMAX.
   2. Turn off climbing image in the beginning and turn it on when the path almost converge.
   3. If the above three doesn't help, try to set a small NSW and resubmit the job when it finishes. In this way, the basis sets can be reset during cell changing and the forces and stress are more accurate.

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.

[shyuep]

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.

[mkhorton]

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.

[shyuep]

@HanmeiTang Improve the doc so that it is clear. Just leave SS-NEB for now.

[acrutt]

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:

• Input of two end point structures, number of images, etc.
• Runs relaxation/structure optimization of both end point structures
• From end point relaxation output structures, generates images from linear interpolation
• Write input files and runs NEB calculation

NEB Workflow:

• Input of a list of end point and image structures [ep1, im0, im1..., ep2] - relaxed end points are assumed
• Write input files and runs NEB calculation (single round, no built-in functionality for multiple NEB runs with various parameters)

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...

• Developing a firetask that would parse NEB outputs and store them in a database. Since my understanding is the current atomate VaspDrone cannot parse NEB outputs, this is something that would require significant development. Additional possible complications include that NEB outputs can be stored differently depending on if VASP or VASP compiled with VTST is used.
• Automating more exotic variations of NEB
• Including built-in checks for correctly initializing NEB (supercell large enough for avoiding periodic boundary conditions, images provided make sense, etc.)

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!

[computron]

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.

[acrutt]

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).

[mkhorton]

Getting started on the basic NEB workflow @acrutt suggested sounds like a great idea.

Regarding alternative interpolation schemes etc., I think integrating @munrojm's great DiSPy tool into a workflow would be another good future ambition.