Better EDWAV error fix

[dkitch]

The current fix for the EDWAV error is to change the smearing scheme to ISMEAR = 0, which is not a very reliable fix. The origin of this error appears to be a bug in VASP when it is compiled with the default -O2 level of optimization in some versions of the intel compiler. Changing the optimization level to -O1 appears to reliably fix the issue.

I suggest adding a warning or optional switch to an O1-version of VASP to fix the bug, instead of changing the smearing. For what its worth, EDWAV errors only show up when running ALGO = A or ALGO = D, which can't be run with the common ISMEAR = -5 scheme anyways.

[shyuep]

Sure, by all means implement in custodian as a unfixable error.

[dkitch]

I'm mostly suggesting this as documentation because this error has been really annoying for me for over 3 years of projects and there is very little documentation on it available. Recompiling VASP with a different optimization flag is not hard, and adding a warning message suggesting that that's the solution could save people a lot of frustration.

If you don't think that's in line with the purpose of custodian, then please close the issue. Otherwise, I will create a pull request at some point with the warning message implementation.

[shyuep]

I agree this is in line with the purposes of custodian and I am in fact agreeing with your suggestion. What I am asking is that you change the EDDAV fix in custodian to be an "unfixable" error, which means VASP will immediately terminate. The error message can indeed be what you suggested, i.e., please recompile VASP with the O1 flag. I think this is preferable to custodian just blindly changing the ISMEAR and moving on, even with a warning. My experience is that once people are done with a calculation, they seldom go back and read warning messages. Hard termination is a better way.

Just a note that I personally think we (meaning me and associates) have been a bit too cavalier about ISMEAR settings. There are probably better ways to handle this. But that is a separate topic.

[mkhorton]

Agreed we need to be more careful with ISMEAR and should probably look into that more carefully. Slightly unrelated, but I'm not sure the effect of LREAL Auto has been fully explored in the MP dataset either.

[Andrew-S-Rosen]

I agree with what's written here. I have encountered this issue countless times, and it's extremely compilation-dependent. It commonly crops up when Algo = All is used (also Algo = Damped, as mentioned by @dkitch). I don't think ISMEAR is the appropriate fix here. Instead, I think the better change to make is to switch from Algo = All to Normal if a meta-GGA/hybrid functional isn't used. I've opened a PR to address this.

This likely still warrants a warning to the user because many calculations will initially fail if set up with the same Algo = All/Damped flags.

#180 addresses this issue via the new grad_not_orth error handler. Note: If it's decided in the future to make this a nonrecoverable error, be very careful about this because it can also occur when ISMEAR = -5 and ALGO = All (the separate algo_tet error), which is recoverable.

[Andrew-S-Rosen]

@shyuep this can be closed.