Convergence assumed when restarting with altered bq block


Clicked A Few Times
Hi,

I've run into a problem with NWChem 6.3 when restarting a calculation having changed the coordinates in a bq block. In this case NWChem wrongly assumes that the SCF is converged and doesn't perform any calculation.

Running the following inputs in succession reproduces the problem:

title "bq"
start nwchem
geometry print units bohr nocenter noautoz
symmetry c1 tol 0.0
zn 0.00000000000000 0.00000000000000 0.00000000000000
end
bq 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
task scf gradient


title "bq2"
restart nwchem
geometry print units bohr nocenter noautoz
symmetry c1 tol 0.0
zn 0.00000000000000 0.00000000000000 0.00000000000000
end
bq 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
task scf gradient


In the second calculation the message "The SCF is already converged" is printed and no calculation is performed.

I've traced the problem back to the function movecs_converged in ddscf/vectors.F, which appears to check that a bq block exists but not whether the coordinates or charges inside it have changed.

I've found a workaround which is to add the line "set scf:converged false" in the second input, but it would be preferable I think for the code itself to check for changes to the bq block.

Tom

Forum Regular
This problem has been fixed in the development version of the code with revision r22066. The check has been implemented such that the code is backward compatible with old movecs files. However, if the code finds an old movecs file it will now automatically assume the calculation was not converged, as that is the only save assumption.

Clicked A Few Times
Hi Huub,

Doesn't r22066 predate the release of version 6.3? From the logs it's stamped Feb 2012. You could well be right as I haven't tried the above tests with the trunk code, but I did have a look at the latest version of ddscf/vectors.F in the repository and it doesn't appear to have changed in any significant way since the version of 6.3 I have (dated 28 May 2013). The changes in vectors.F from r22066 are in my version of the code. Or is the bug fixed elsewhere?

I'll try building from the trunk and testing again but could you confirm whether the two inputs above work successfully for you?

Thanks a lot,

Tom

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

Clicked A Few Times
Hi Huub,

Thanks for confirming the problem. I haven't looked closely into this but I think in the case of the geometry block there is some kind of checksum over the actual coordinates. I guess an equivalent checksum could be added for bq block coordinates.

Tom

Forum Regular
Hi Tom,

I have written that checksum routine now. I just need to run a few tests before I check it in. I'll get back to you when I am done.

Huub

Forum Regular
Hi Tom,

I have just checked the fix for this problem in. Please update the src/bq and src/ddscf directories of the development version to pick this fix up. The changes are in src/bq/bq_checksum.F src/bq/bq.fh src/bq/GNUmakefile and src/ddscf/vectors.F. Please let me know if you bump into any other unexpected behaviors.

Best wishes, Huub

Clicked A Few Times
Thanks Huub, it's working for me now.

Tom


Forum >> NWChem's corner >> Running NWChem