Known issues: Difference between revisions

Revision as of 09:55, 23 May 2022

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

@@ Line 11: / Line 11: @@
 ! Date   !! style="text-align:center;"| Version first noticed !! Version fixed !! Description
 |-
-| 2022-05-11  ||style = "background:#EAAEB2"| 6.3.1 ||style = "background:#9AB7FE"| to be announced ||
+| 2022-05-11  ||style = "background:#EAAEB2"| 6.3.1 ||style = "background:#9AB7FE"| 6.3.2 ||
 '''ML_ISTART=1 fails for some scenarios''': Due to a bug in the rearrangement of the structures found on the {{FILE|ML_AB}} file, restarting the training of a force field by means of {{TAG|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.