Use last structure from a VaspRelaxWorkchain failed with exit code 401 (maximum number of iterations exceeded)

[sylviancadars]

Dear aiida-vasp developpers,

I am working on a workflow that sequentially performs 'VaspRelaxWorchain's. When the max number of ionic steps is reached, the VaspRelaxWorchain is repeated up to inputs.max_iterations times. If however an optimum has not been found at that stage the worchain exits with error code 401 ('the maximum number of iterations was exceeded') and no output is produced. When this happens my workchain continues but uses as the current structure the same initial structure as for the previous run rather than the last structure.

Because I gradually increase the calculation accuracy in distinct VaspRelaxWorchain's, I would like to have the possibility to use a small inputs.max_iterations (possibly even 1 but for the final VaspRelaxWorchain step) and keep the last structure for the next VaspRelaxWorchain even though the optimum has not been reached (I would then simply point out the 'ionic_converged = False' status of this step within the overall process).

Is there a way to do this without modifying the VaspRelaxWorkchain itself ?

I am thinking of fetching the CONTCAR file from the RemoteFolderData if the exit code is 401. Would this be possible and potentially compatible with the AiiDA data provenance philisophy ?

Thanks. Best regards.

Sylvian

[zhubonan]

Hi Sylvian,

If you are using the development branch, the relaxation is controlled at two levels, this is slightly different from the pypi version where the VaspWorkChain is not doing much as for correction/restarts:

1. VaspWorkChain where the VaspCalculation is repeated until it reaches ionic convergence (with certain maximum iterations), otherwise it would end with a none-zero exit status without outputs (e.g. 401).
2. VaspRelaxWorkChin where the input and output structures are checked for convergence. This is because VASP itself only checks for forces or energy, and nothing else. Also, restarts must be performed due to the fixed basis set, and the final static calculation to get technically "correct" energy. By default, if a VaspWorkChain fails, it inherits its exit status ( this is way you see 401).

For your use case, e.g. with increasing accuracy (I assume you mean to change parameters other than just EDIFFG), I am afraid you will have to make your own relaxation work chain for this, rather than running a sequence for VaspRelaxWorkChain, as the latter is designed to be "run until it converges and stop if there are problems". However, you can create your custom workflow as a subclass of the VaspRelaxWorkChain and reuse many of the methods.

You probably will have to write a handler for inspecting "failed as expected" VaspWorkChain (with non-zero exit status). Note that you still have access to the lower level VaspCalculation using QueryBuilder. The CONTCAR is always retrieved and parsed as output structure at the VaspCalculation level, there is no need to manually fetch from the RemoteFolder. So you can query the output structure of the last VaspCalculation, and use it for the next iteration of your custom VaspIncrAccRelaxWorkChain.

[sylviancadars]

Thank you so much @zhubonan. This is extremely helpful... even though the part about not being able to use the VaspRelaxWorkchain is the answer I was afraid to read after weeks trying to have a workflow more-or-less working ! Hopefully the VaspRelaxWorkChain subclassing will not be too difficult to implement (and I am and will keep learning A LOT in the process anyways).

And yes with "increasing accuracy" I mean gradually changing : ENCUT, EDIFF, EDIFFG, KPOINTS_SPACING, the choice of relaxation algorthim, optimizing atomic positions only in the first steps and only then cell shape and volume, changing also ISMEAR between optimization and final SPE calculation, etc. This is a protocol I tried to optimize as I was working with a structure-prediction code (USPEX) producing very bad initial structures that often required many ionic steps to ultimately converge (if converging at all).

I'll be happy to share my workflow at some point if it can be of interest to the community.

It will certainly take me some more time trying to apply your suggestions, and I will probably get back to you with more questions in a few days (or weeks) if you don't mind leaving the issue open in the meantime.

Again, thank you very much for your help. Best regards. Sylvian.

[espenfl]

@sylviancadars Thanks a lot for mentioning this. Several users are already running workchains which supports more extensive relaxations, such as for instance iterating over multiple sets of smaller iterations such that one can monitor if the convergence starts to slow down and measures need to be taken. These workchains typically use PREC more than explicit ENCUT parameters etc. in order to be broadly compatible, but offer a step up of the current basic relaxation workchain.

It is great that you want to share your workflow as well. Thanks a lot.

When I am back from vacation I can have a look at it and try to clean it and open a pull request with it. Then if you have not started to work in it, you can use that for inspiration, or we can continue to work on that together if you want.

[zhubonan]

I think this is a good use case and may be useful for other applications as well. For example, implement a multiple-stage relaxation that would also increase the theory. @espenfl We could include one of such workchain as an example for extending existing workflows.