VCNEB (QE interface) silently truncates at Step 2, regardless of optRelaxType / VarPathLength / ConvThreshold

[Kenneth Park]

Hi all,

I'm running USPEX v10.6 (updated from the 10.5 base install via the update_files.zip patch) with the Quantum ESPRESSO interface (abinitioCode = 8, QE 7.3.1) for a VCNEB phase-transition-pathway calculation (SiO2, rutile-type -> columbite-type, 11 images, 160 GPa). I'm running into a reproducible bug where the calculation always stops after VCNEB Step 2, with a truncated report and no error message.

SYMPTOM

The run proceeds normally through the initial step and Step 1 (all images relax, energies and forces reported normally, activation energy printed correctly). At Step 2, only Image 1 is evaluated, the activation energy lines are printed blank, and the run terminates cleanly (exit status 0, no MATLAB error, no QE error) with:

VCNEB Calculation Step 2 finished ....... THE VCNEB JOB finished !

I initially suspected this was a legitimate convergence (ConvThreshold met), but I've since ruled that out -- see below.

WHAT I'VE RULED OUT

I've reproduced this exact failure (truncation at Step 2, blank activation energy) across the following independently-varied settings, all with the same 11-image seed pathway and same QE Specific/ files:

• optRelaxType = 3 (full atom + cell relaxation)
• optRelaxType = 2 (cell-only relaxation, atoms frozen -- confirmed via VCNEBReports showing Atom Forces RMS = 0.000 throughout, so the setting is being correctly applied internally)
• ConvThreshold ranging from 0.01 down to 0.0002 eV/A (i.e. an essentially unreachable threshold) -- truncation still occurs at Step 2 regardless, ruling out genuine force convergence as the cause
• VarPathLength = 0.3 and 1.0 (to control whether the variable-image-number method was inserting new images and hitting some image-count-related limit) -- truncation at Step 2 occurs either way, including when the image count stays fixed at 11
• K_min/K_max = 3/6 and 15/30 (spring constant stiffness)
• KresolStart = 0.40 and 0.20 (k-point mesh; note KresolStart appears to have no effect on the resulting K_POINTS card in this build -- both values produced an auto-appended 2x2x2 mesh; see separate note below)

In every combination, the trajectory through the initial step and Step 1 is physically reasonable (energies decrease sensibly toward lower activation energy from Step 0 to Step 1: 21.956 eV -> 19.234 eV in the run below), and QE itself completes every single-point SCF call cleanly (JOB DONE, no errors) right up to and including the truncation point.

REPRESENTATIVE INPUT.txt

VCNEB : calculationMethod

% numSpecies 4 8 % EndNumSpecies

% atomType Si O % EndAtomType

160.0 : ExternalPressure 111 : vcnebType 11 : numImages 500 : numSteps 1 : optimizerType 1 : optReadImages 2 : optRelaxType 0.1 : dt 0.0002 : ConvThreshold 1.0 : VarPathLength 15 : K_min 30 : K_max 0 : optFreezing 0 : optMethodCIDI 2 : FormatType 1 : PrintStep % abinitioCode 8 % ENDabinit % commandExecutable mpirun pw.x < qe.in > output % EndExecutable 1 : numParallelCalcs % KresolStart 0.20 % Kresolend

Images file uses optReadImages=1 with independently DFT-relaxed endpoints (VASP5 POSCAR format, Image_ini / Image_end labels).

RELEVANT VCNEBReports EXCERPT (optRelaxType=2 run)

------------------------------ VCNEB step : 2 ----------------------------- Cell Forces RMS(eV/A) Atom Forces RMS(eV/A) Image Energy-(eV) Total, Project, Elastic Total, Project, Elastic F Dist SpaceG 1 -3912.0535 [ 15.832, 15.832, 0.000] [ 0.000, 0.000, 0.000] 0 0.0000 58

Activation energy (->) = eV Activation energy (<-) = eV

===================================== VCNEB DONE ====================================

Only Image 1 (a fixed endpoint) is listed; Images 2-11 are simply missing from this step's block, and the activation energy fields are blank rather than 0.000 or any numeric value -- this looks like the report-writing routine is being cut off mid-write, rather than the calculation genuinely completing.

SEPARATE, POSSIBLY RELATED NOTE ON KresolStart

Independently of the above, I could not get KresolStart to influence the k-point mesh at all for VCNEB+QE -- 0.40 and 0.20 both produced an auto-appended "K_POINTS {automatic} / 2 2 2 0 0 0" card in the generated qe.in. I don't know whether this is related to the Step 2 truncation, but wanted to mention it in case it's a symptom of the same underlying issue in how VCNEB's QE interface consumes INPUT.txt options.

QUESTIONS

1. Is this a known issue with VCNEB + QE in v10.6 (or the 10.5->10.6 patch specifically)?
2. Is there a log file (beyond stdout and VCNEBReports) that would show what NEB_writeFiles / VCNEB.m is doing internally at the point of truncation? I'd be happy to dig further with pointers to the right debug flags or verbosity settings.
3. Has anyone successfully run VCNEB with the QE interface for more than ~2 steps? Any known-working example INPUT.txt for a multi-species QE system would help me isolate whether this is specific to my setup.

Happy to share the full run directory (INPUT.txt, Images, Specific/qEspresso_options_1, and stdout logs from four independent runs reproducing this) if useful.

Possibly related: a recent thread here ("USPEX 10.6 VCNEB continues running although all printed RMS forces are below ConvThreshold," Jeff Armstrong, Aug 6) reports what looks like the inverse symptom -- VCNEB failing to stop when it should, rather than stopping when it shouldn't -- using the VASP interface (abinitioCode=1) rather than QE. Given both issues involve the convergence-check/reporting logic around ConvThreshold, they may share a root cause and could be worth looking at together.

Thanks very much for any pointers.

Ken Park 

Baylor University