Convergence assumed when restarting with altered bq block


Click here for full thread
Forum Regular
Hi Tom,
You are right. Even with the current development version your two input files do not work. What does work are the two input files given below:

 title "bq"
start nwchem
geometry print units bohr nocenter noautoz
symmetry c1 tol 0.0
zn 0.00000000000000 0.00000000000000 0.00000000000000
end
bq "bq1" units au
force force.dat
3.77945332702064 0.00000000000000 0.00000000000000 1.7544100000
0.00000000000000 3.77945332702064 0.00000000000000 2.0000000000
3.77945332702064 3.77945332702064 0.00000000000000 1.7544100000
3.77955332700930 0.00000000000000 0.00000000000000 -3.7544100000
3.77955332700930 3.77945332702064 0.00000000000000 -3.7544100000
end
basis print
Zn library 3-21g
end
charge 0
set bq "bq1"
task scf gradient

and the second one:

 title "bq2"
restart nwchem
geometry print units bohr nocenter noautoz
symmetry c1 tol 0.0
zn 0.00000000000000 0.00000000000000 0.00000000000000
end
bq "bq2" units au
force force.dat
-1.77945332702064 0.00000000000000 1.00000000000000 3.7544100000
2.00000000000000 3.77945332702064 0.00000000000000 2.0000000000
-3.77945332702064 3.77945332702064 0.10000000000000 1.7544100000
-4.73438431265977 -0.0351280747192 0.00000000000000 -3.7544100000
-5.73402714291460 3.81558680667045 1.00000000000000 -3.7544100000
end
charge 0
set bq "bq2"
task scf gradient

So what is different? The difference is that in your input files the implied name of the Bq block is the same in both cases but the contents has been changed. In the two input files I have listed here the Bq blocks have different names and I switch between one and another. The fixed code will save the name of the Bq block in the movecs file. So when you read the movecs file and the currently active Bq block name does not match the stored name the code detects that the movecs are not converged. However, if the Bq block names match then the code currently has no way of knowing that you have changed the Bq block contents in the meantime. I need to check how we handle that in geometries currently (the same problem must arise there).

Huub