Known issues

Below we provide an incomplete list of known issues. Please mind the description to see whether the issue has been fixed.

Color legend: Open Resolved Planned Obsolete

Date	Version first noticed	Version fixed	Description
2023-10-31	<6	>=6	For LORBIT >= 11 and ISYM = 2, the partial charge densities are not correctly symmetrized. This can result in different charges for symmetrically equivalent partial charge densities. For older versions of VASP, we recommend a two-step procedure: 1. Self-consistent calculation with symmetry switched on (ISYM=2) 2. Recalculation of the partial charge density with symmetry switched off (ISYM=0) To avoid unnecessary large WAVECAR files, we recommend setting LWAVE=.FALSE. in step 2.
2021-11-12	5.4.4	6.3.2	Ionic contributions to the macroscopic polarization with atoms at the periodic boundary: Removed a section of code from POINT_CHARGE_DIPOL that adds a copy of the atom when it is at the periodic boundary. This can lead to a different value of "Ionic dipole moment: p[ion]" being reported in the OUTCAR with respect to previous versions of VASP. This result, although numerically different is still correct since the polarization is defined up to integer multiples of the polarization quantum. Thanks to Chengcheng Xiao the bug report.
2023-10-19	6.2.1	still open	Phonon calculations (IBRION = 6) fails for some trigonal cells with ISIF = 3: VASP prints a bug error message complaining that it could not find some k points of the original mesh in the larger one with reduced symmetry of a distortion. As a fix, you can set KBLOWUP = F to circumvent this error message while we work on a fix. Thanks for barshab for the bug report.
2023-05-31	6.4.0	6.4.2	Fast-mode predictions will crash together with finite difference (IBRION=5,6): At the end of the calculation the fast-mode is supposed to deallocate important arrays using NSW. In the finite differences method NSW is not used and the fast-mode can wrongly deallocate at an earlier stage. This results in an error if the code wants to access the deallocated arrays. Until a patch is released we suggest two possible quick fixes: (1) Avoid explicit deallocations at the end of the program and let the compiler deallocate when the code runs out of scope. For that remove lines 568, 569, 570 and 572 in the ml_ff_ff2.F file. (2) Avoid the fast-prediction mode: Retrain the MLFF without support for the fast mode, i.e., use ML_MODE = refitbayesian instead of refit. Use the resulting ML_FFN file for the ML_MODE = run production runs. Unlike suggestion (1) this does not require a recompilation of VASP but unfortunately MD runs will take significantly longer. Thanks for Soungminbae for the bug report.
2023-05-17	6.4.0	6.4.2	Incorrect MLFF fast-mode predictions for some triclinic geometries: Due to an error in the cell list algorithm the MLFF predictions (energy, forces and stress tensor) in the fast-execution mode (ML_MODE = run) may be incorrect for triclinic systems with small or large lattice angles (i.e., large deviations from right angles). Until a patch is released we suggest two possible quick fixes: (1) Avoid using the cell list algorithm for neighbor list builds (recommended): Add this%algo_type = 2 in a new line below line 923 in src/ml_ff_neighbor.F and recompile VASP, or, (2) Avoid the fast-prediction mode: Retrain the MLFF without support for the fast mode, i.e., use ML_MODE = refitbayesian instead of refit. Use the resulting ML_FFN file for the ML_MODE = run production runs. Unlike suggestion (1) this does not require a recompilation of VASP but unfortunately MD runs will take significantly longer. Thanks to Johan for a very detailed bug report.
2023-05-15	6.4.1	6.4.2	Bugs in interface to wannier90: If no projections are supplied (e.g. LOCPROJ, LSCDM) and there are no projections found in the wannier90 input file, VASP does not produce the UNK files. This also leads to a crash if LWANNIER90 RUN is used. The format of the UNK files is broken for the gamma-only version of VASP. Thanks to guyohad for the bug report.
2023-03-07	6.4.0	6.4.1	Output of memory estimate in machine learning force fields is wrong for SVD refitting: The SVD algorithm (ML_IALGO_LINREG=3, 4) uses the design matrix and two helping arrays with the size of the design matrix. In the memory estimates these two helping arrays are not considered correctly. The entry "FMAT for basis" at the beginning of the ML_LOGFILE should be three times larger. The algorithm will be fixed such that it only requires twice the design matrix arrays instead of three times and the outputs for the estimates will contain the correct values.
2023-03-07	6.4.0	6.4.1	Bug in sparsification routine for machine learning force fields: This bug effects more severely calculatoins where the number of local reference configurations is getting close to ML_MB. By setting ML_MB to a high value this bug can be avoided in most cases (there are still some cases, especially where a small number of local reference configurations is picked and the structure contains many atoms per type or ML_MCONF_NEW is set to a high value). This bug can especially affect refitting runs, resulting in no ML_FFN file.
2023-03-07	6.4.0	6.4.1	ML_ISTART=2 on sub element types broken for fast force field: When the force is trained for multiple element types, but the production runs (ML_ISTART=2) are carried out for a subset of types, the code most likely crashes. This bug will be urgently fixed.
2023-02-20	6.2.0	6.4.1	INCAR reader issues: Moving an INCAR file from a system with Windows line endings to a Unix-based system can cause the INCAR reader to fail. As a workaround convert the INCAR file to Unix line endings e.g. by :set ff=unix in vi. Comments lines do not work properly with inline tags separated by semicolon if the comment character occurs before the semicolon but not at the beginning of the line. As a workaround, split the tags over multiple lines so that you can comment out what you want. Please also refer to the OUTCAR file and see whether VASP understood your input.
2023-02-17	6.4.0	6.4.1	Corrupt ML_FFN files on some file systems: Insufficient protection against concurrent write statements may lead to corrupt ML_FFN files on some file systems. The broken files will often remain unnoticed until they are used in a prediction-only run with ML_ISTART=2. Then, VASP is likely to exit with some misleading error message about incorrect types present in the ML_FF file. As a workaround it may help to refit starting from the last ML_AB file with ML_MODE=refit which may generate a working ML_FFN file (this is anyway highly recommended to gain access to the fast execution mode in ML_ISTART=2). Alternatively, there is a patch for VASP.6.4.0 available (see attachment to this forum post). Thanks a lot to xiliang_lian and szurlle for reporting this and testing the patch.
2023-01-18	6.3.2	6.4.0	makefile.include template does not work for AOCC 4.0.0: The flang preprocessor explicitly requires specifying that the code is in free format -ffree-form. In earlier versions of VASP you can add this flag to the CPP rule in the makefile.include. Thanks to liu_jiyuan for reporting this bug.
2022-11-23	6.1.0	6.4.0	Memory leak in MD in OpenMP version compiled with AOCC and NV: the problem originates from the DEFAULT(PRIVATE) clause in SET_DD_PAW in paw.F because the NV and AOCC compilers do not correctly clean up the memory for arrays that were allocated outside the OMP PARALLEL region and used as private inside. We advise against compiling with OpenMP support with the NV and AOCC compilers for vasp <= 6.3.2.
2022-08-29	6.1.0	6.2.0	Inconsistent energy for fixed electron occupancies: Rickard Armiento pointed out that the HF total energy for fixed electron occupancies was inconsistent when compared to 5.4.4 or older versions. This bug was introduced in 6.1.0 in order to support IALGO=3 in combination with ISMEAR=-2 (for SPHPRO calculations as post-processing step) but broke the CG algorithms (IALGO=53) The fix was added in src/main.F with IF (INFO%LONESW .OR. (INFO%IALGO==3 .AND. KPOINTS%ISMEAR/=-2)) THEN \n IF (INFO%LONESW) W_F%CELTOT = W%CELTOT .
2022-05-11	6.3.1	6.3.2	ML_ISTART=1 fails for some scenarios: Due to a bug in the rearrangement of the structures found on the ML_AB file, restarting the training of a force field by means of ML_ISTART=1 fails in some cases. N.B.: this problem only occurs in a scenario where one repeatedly restarts the training, and returns to training for a structure that was trained on before (that means exactly same element types and number of atoms per element), but not immediately before. Example: one starts training a force field for structure A, follows this by a continuation run to train for structure B, and then restarts a second time returning to training for structure A again.
2022-05-05	6.2.0	6.3.1	Treatment of the Coulomb divergence in hybrid-functional band-structure calculations is only correct for PBE0: The Coulomb divergence correction for states at and near the Γ-point in hybrid-functional band-structure calculations (see HFRCUT) was only correctly implemented for PBE0 and HFRCUT=-1. Note: HSE band-structure calculations are not expected to be (strongly) affected because this hybrid functional only includes “short-range” Fock exchange.
2022-03-14	6.2.0	6.3.1	Bug in interface with Wannier90 for non-collinear spin calculations: The spin axis for non-collinear spin calculations is not correctly read from the wannier90 input file. This is because this line in the mlwf.F file: MLWF%LPRJ_functions(IS)%spin_qaxis = proj_s_qaxisx(3,IS) should instead be: MLWF%LPRJ_functions(IS)%spin_qaxis = proj_s_qaxisx(:,IS). Thanks to Domenico Di Sante for reporting this bug.
2022-02-04	6.3.0	6.3.1	Incompatibility with Fujitsu compiler: Fujitsu's Fortran compiler does not support overloaded internal subroutines. A simple workaround is to compile without machine-learning–force-fileds capabilities. Comment out the macro definition of ML_AVAILABLE in line 626 of src/symbol.inc by adding a ! in front, i.e. it should look like this: !#define ML_AVAILABLE. Then do a complete rebuild of VASP: run make veryclean followed by your desired build command.
2021-05-28	6.2.0	6.3.0	Bug in interface with Wannier90 writing UNK when exclude_bands present: The UNK files generated by VASP include all bands where bands specified by `exclude_bands` should be excluded. The fix is to pass the `exclude_bands` array to `get_wave_functions` in mlwf.F. Thanks to Chengcheng Xiao for reporting this bug.

---