Page 1 of 1

Positions do not update after one step

Posted: Wed May 14, 2014 9:32 am
by huberl
I am seeing no update in atomic positions after one atomic step (NSW=1), checked for both IBRION=1 and 2. This conflicts with an earlier admin comment that atomic updates are done at the end of the self-consistent electronic cycle.

Documentation for the CG algorithm seems to be a little bit conflicting, where the table
NSTEP:
1 initial position
2 trial step
3 corrector step, i.e. positions corresponding to anticipated minimum...

seeming to imply that no update occurs until the second step, but the text
The conjugate gradient method requires a line minimization, which is performed in several steps: i) first a trial step into the search direction (scaled gradients) is done

implying that an update happens in the first step.

At the end of the first SC cycle, one has forces for all the atoms and can make some sort of guess for new positions, but it appears as though the user doesn't get to see any such guesses until the completion of at least two SC cycles.

Perhaps I misunderstand something about why the update is made at the start of a cycle instead of the end, but it seems wasteful and contradicts the admin comment so I thought I'd throw it up as a bug report.

Regards,
-Liam

Positions do not update after one step

Posted: Fri Aug 01, 2014 7:54 am
by admin
please
compare POSCAR and CONTCAR (have you done so?)
make sure that you have not set 'Selective Dynamics' and F (position not updated along that direction) in POSCAR

Positions do not update after one step

Posted: Tue Aug 05, 2014 9:28 pm
by huberl
Yes, POSCAR=CONTCAR; this is my concern. No, 'Selective Dynamics' were not enabled.

What is happening is not necessarily a 'bug', but could be interpreted as a 'feature'. However, the current behaviour is inconsistent with the documentation/admin comments (see previous post) and also makes NSW=0 redundant since it behaves the same as NSW=1.

Minimal working example that runs very quickly:

POTCAR = Al USPP
INCAR:
NSW = [-1, 0, 1, 2]
ISIF = [both 1 and 2 tested]
IBRION = 1
EDIFFG = 1e-4
KPOINTS:
Automatic
0
Monkhorst-pack
11 11 11
POSCAR:
Bulk Al
3.9729664827511101
1.0 0.0 0.0
0.0 1.0 0.0
0.0 0.0 1.0
4
Direct
0.0 0.0 0.0
0.4 0.5 0.0
0.5 0.0 0.5
0.0 0.5 0.5
Where the POSCAR is simply unit cell Al with the second atom displaced a bit. When...
NSW = -1, 0, 1
A single electronic cycle runs. CONTCAR = POSCAR. I see no differences among these three in positions or forces written to OUTCAR.
NSW = 2
Two electronic cycles run. CONTCAR != POSCAR. Positions other than the initial ones written to OUTCAR.

Those results are the same with CG and quasi-Newton relaxation. With NSW = 1 (2), there are 1 (2) sets of atomic positions written to OUTCAR, including the initial positions given in the POSCAR. This indicates that updated positions are written at the beginning of cycles rather than the end. Apart from inconsistencies with the documentation, the only real "bug" here is that it seems wasteful to calculate all the forces then never write the updated positions based on these forces.

Not being particularly familiar with FORTRAN, I brought this issue to a more knowledgeable colleague. He suggested that switching the order of
CALL IONCGR
and
write
around line 3300 in main.F may resolve the issue. I haven't recompiled VASP with this change and may have misunderstood him, but hopefully this is helpful for anybody else interested in this issue.

Regards,
-Liam