Issue reading IOPT in opt.F (also question about VTST website)

[ehermes]

I was recompiling VASP 5.3.5 today using the latest vtstcode 158 (as well as the latest VASPsol and some custom patches of my own), and I encountered an issue wherein VASP would not correctly parse the IOPT value in the INCAR. Specifically, the IOPT parameter was defaulting to 0 regardless of the value supplied to the INCAR. After some debugging I found that the RDATAB function called on line 98 to parse the IOPT setting was returning an IERR of 3, which indicates that the keyword was not found in the file. The POTIM and IBRION settings (which are gathered immediately after IOPT) were being parsed correctly.

I found that putting the IOPT setting into a separate file and changing the RDATAB command to read from that file worked as expected. Additionally, I found that changing the command from "RDATAB(.TRUE.,'INCAR',..." to "RDATAB(.FALSE.,'INCAR'..." resulted in the IOPT value being read properly. I notice that in most of the places that RDATAB is called in the VASP source code, it is called with .FALSE. in the first argument place. My understanding is that using .FALSE. causes VASP to rewind the already-open INCAR file, rather than re-open it.

EDIT: It looks like I also needed to make that change in chain.F. Strangely, it seems like the only keyword to have this issue is IOPT.

EDIT 2: Apparently changing the .TRUE. to .FALSE. in chain.F doesn't solve the issue. The OUTCAR indicates that the LBFGS method is being used (as printed in opt.F), but the atoms are essentially not moving and the energy and forces do not change from step to step. I haven't quite yet figured out how to solve this.

Also, though this is completely off topic, I've been meaning to ask about the VTST download page. Specifically, the download page says that a snapshot of the VTST code can be downloaded from the SVN repository at http://theory.cm.utexas.edu/svn/vtsttools. However, as far as I can tell, this repository contains the actual VTST website, rather than any of the code. Am I correct in thinking that this link should be to http://theory.cm.utexas.edu/svn/vtstcode/ instead? If so, how is this any different than the vtstcode.tgz that is distributed, as both have the same revision number?

[graeme]

Thank you for the very detailed bug report. We'll try to reproduce these problems and find a solution. If you can post your INCAR, that might be helpful. It's unlikely, but you might check for special characters in the INCAR file.

With regards to the svn repository vtsttools: this should contain the documentation (in /docs), the vtstscripts (in /vtstscripts) and the vtstcode (in /vtstcode). The later two are included as sub-repositories and are in the subdirectories mentioned. Whenever there are significant changes, I tar things up and give it a new release number.

[ehermes]

I have attached the POSCAR, INCAR, and KPOINTS files used to run this calculation. I am using the latest 10-electron Pd PAW from 04Jan2005. Additionally, as I forgot to mention this before, I am using VASP 5.3.5 (Edit: I guess I didn't forget to mention it...).

[graeme]

I am not able to reproduce this error. Running with your files gives the following lines in the OUTCAR:

----------
CHAIN: initializing optimizer

OPT: Using LBFGS optimizer
OPT: LBFGS, Init
OPT: LBFGS, MEMORY 20
OPT: LBFGS, IMAGES 1
OPT: LBFGS, MAXMOVE 0.200000
OPT: LBFGS, LGLOBAL T
OPT: LBFGS, INVCURV 0.010000
OPT: LBFGS, LLINEOPT F
OPT: LBFGS, FDSTEP 0.005000
OPT: LBFGS, LAUTOSCALE T
OPT: LBFGS, DAMPING 2.000000

CHAIN: Read ICHAIN 0
----------

which is a correct interpretation of the INCAR.

One more suggestion, if you have been modifying the source files. Check again with a make clean and a fresh build. I know this is not likely the source of the problem but there have been a number of times when stale object files lead to strange debugging tests.

[ehermes]

It would appear that the error only occurs when both VASPsol and VTST are patched into VASP. I'm unclear as to why this is the case, since VASPsol's modifications seem to be largely orthogonal to VTST's. As far as I can tell, the way that VASPsol parses the INCAR is entirely consistent with the way that VASP does it, whereas VTST does so in a different fashion. Specifically, both VASPsol and readers native to VASP (e.g. those in reader.F) first open the INCAR with "OPEN(UNIT=IO%IU5,FILE='INCAR',STATUS='OLD')", call RDATAB with "CALL RDATAB(.FALSE.,'INCAR',IO%IU5,..." , then close the INCAR again with "CLOSE(IO%IU5)". On the other hand, VTST never explicitly opens or closes the INCAR, and instead calls RDATAB with "CALL RDATAB(.TRUE.,'INCAR',IO%IU5,...", which I suspect works only coincidentally as no built-in VASP code seems to call RDATAB in this way.

I have attached a patch that makes VTST read the INCAR in a way that is more similar to how VASP does it. This is a quick and dirty patch, and should probably be done with more care. Additionally, it doesn't actually solve my problem -- with the modified VTST patch, the OUTCAR indicates that the settings are being read properly, but the atoms still aren't moving and the energy and forces still are not changing. For now I am going to go without VASPsol, but it would be very helpful to be able to use both simultaneously.

Edit: I've deleted the attachment as I have confirmed that this change actually causes the issue I described above. Patching the latest VTST onto an otherwise unmodified VASP 5.3.5 works fine, though patching my modified VTST causes the atoms to not move (very much, if at all) between ionic steps.

Edit 2: To be clear, VTST still doesn't work with VASPsol. I'm going to try to fix my patch and see if I can get them to play nice together without breaking anything in the process.

[ehermes]

I seem to have solved the issue. I have attached a patch that modifies the VTSTtools routines so that each subroutine that reads from the INCAR manages opening and closing of the file itself, which is consistent with how the rest of VASP's subroutines parse the INCAR.

There seems to be an additional problem with VASPsol not properly closing the INCAR after reading it, and I have submitted a pull request to them that solves this issue. However, the modifications I've made to VTSTtools are sufficient to provide compatibility between the two patches.

Eric Hermes

[graeme]

Ok, perfect, again thanks for getting to the bottom of this!

[ehermes]

I apologize for bumping this thread, but I just wanted to clarify: My last post has a patch which fixes a subtle bug in the VTST patches for VASP, relating to parsing the INCAR. I would appreciate it if someone could take a look and verify that my fix is valid. I've been using my modified version for a while now, and everything seems to be working fine.