Known issues: Difference between revisions

From VASP Wiki
No edit summary
No edit summary
Line 10: Line 10:
|-
|-
! style=width:5em | Date    !! style="text-align:center;"| Version first noticed !! Version fixed !! Description
! style=width:5em | Date    !! style="text-align:center;"| Version first noticed !! Version fixed !! Description
|-
| 2023-01-18  ||style = "background:#EAAEB2"| 6.3.2 ||style = "background:#9AB7FE"| > 6.3.2 ||
'''makefile.include template does not work for AOCC 4.0.0''': The ''flang'' preprocessor explicitly requires specifying that the code is in free format <code>-ffree-form</code>. In earlier versions of VASP you can add this flag to the <code>CPP</code> rule in the makefile.include. Thanks to [https://www.vasp.at/forum/memberlist.php?mode=viewprofile&u=66916 liu_jiyuan] for reporting [https://www.vasp.at/forum/viewtopic.php?f=2&t=18802 this bug].


|-
|-

Revision as of 14:02, 23 January 2023

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-01-18 6.3.2 > 6.3.2

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

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.



Contents