Hello,
When I set EDIFFG in the INCAR file, it is not taken correctly into account. By example, with EDIFFG=-0.001in the INCAR file, I get in the OUTCAR file:
EDIFFG = .0E+00 stopping-criterion for IOM
The problem seems to come from the chain.F file where EDIFFG is redeclared and read. The workaround I found was to add an argument to the chain subroutines and give it from main (dyn%ediffg variable). Is this correct or is there a better solution?
Problem with the EDIFFG parameter
Moderator: moderators
First, thank you for this bug report. We have not seen this problem on our machines, so we would like to get to the bottom of this.
I don't understand how this error is related to our reading of EDIFFG in chain.F. The EDIFFG variable is local to that module, and should not conflict with the dyn%ediffg variable that is used elsewhere in vasp.
We would prefer not to modify the call to chain_init and chain_force, so that the code can be built without modifying main.F. If there really is a name conflict, we can modify the local name of ediffg (to ediffg_local) in chain.F. Dan Sheppard has done this and we have put an updated version, 2.02a, on the webpage.
Can you try this out and see if the problem is solved? If the problem is not fixed, we would like to see your input files, and understand what is going wrong.
Thanks again for your help,
Graeme
I don't understand how this error is related to our reading of EDIFFG in chain.F. The EDIFFG variable is local to that module, and should not conflict with the dyn%ediffg variable that is used elsewhere in vasp.
We would prefer not to modify the call to chain_init and chain_force, so that the code can be built without modifying main.F. If there really is a name conflict, we can modify the local name of ediffg (to ediffg_local) in chain.F. Dan Sheppard has done this and we have put an updated version, 2.02a, on the webpage.
Can you try this out and see if the problem is solved? If the problem is not fixed, we would like to see your input files, and understand what is going wrong.
Thanks again for your help,
Graeme
Hello,
I investigated a little bit more the problem and you are right the problem does not seem to come from the EDIFFG variable in the chain.F file. In fact, the value dyn%ediffg is lost during the call to the subroutine reader. It is read correctly but later in the subroutine between two calls to rdatab, its value is lost. It looks like a memory bug or something like that because this variable is not used in this part of the subroutine! Therefore, I think it is a VASP problem and not VTSTTools one.
The modifications I did were in fact a workaround. The lost value is read again in chain.F and if I add it as an argument, I get back its value.
I investigated a little bit more the problem and you are right the problem does not seem to come from the EDIFFG variable in the chain.F file. In fact, the value dyn%ediffg is lost during the call to the subroutine reader. It is read correctly but later in the subroutine between two calls to rdatab, its value is lost. It looks like a memory bug or something like that because this variable is not used in this part of the subroutine! Therefore, I think it is a VASP problem and not VTSTTools one.
The modifications I did were in fact a workaround. The lost value is read again in chain.F and if I add it as an argument, I get back its value.