Strange behaviour with TabuSearch

[S0S-90]

When performing a TS-run with the DFTBaby or DFTB+ interface and the CAST optimizer it sometimes breaks.

The error message then is: "An exception occured. The execution of CAST failed. Error: Unqually sized vectors given for dot product."

[Issue copied from the old CAST repository, issue Nr. #78.]

Dot products are used when converting cartesian to internal coordinates. Maybe the error is somewhere in there?

[S0S-90]

The problem doesn't seem to be in the conversion from cartesian to internal coordinates. Maybe in the conversion from internal to cartesian?

Maybe there is a connection to issue #4 as this also only happens with CAST optimizer? There are also dot products in the lbfgs library.

[S0S-90]

The problem also doesn't seem to be in the internal to cartesian conversion.

[S0S-90]

The problem seems to be that the dimer method produces structures that have sometimes NaN as atom coordinates and this leads to errors in calculations performed by some of the energy interfaces. The new DFTB+ interface contains a mechanism to catch such errors. So if strange behaviour occurs with TS and other energy interfaces (sometimes the program also doesn't break but only runs infinetely at the same TS step) you should try to implement such a mechanims also in other energy interfaces.

Maybe it would be a good idea to catch this directly in the TabuSearch algorithm and not in the individual interfaces?

[S0S-90]

NaN coordinates are now also catched in Mopac interface.

[S0S-90]

Now coodinates are checked for NaN in the following interfaces:

• 3-layer
• dftb
• gaussian
• mopac
• oniom
• orca
• psi4
• qmmm

If you implement another interface and want to use the check there it can be done by the function check_structure() which is a member of the Coordinates-Object.

[S0S-90]

As there were still errors of kind "Unqually sized vectors given for dot product." I tried to fix this by commit 10ba56ac95c6822ae3795c2cc7653e23f722ca41. The problem was that a variable (f_rot) was only set in one branch of an if-else loop but used later even if it was not set. I now added a check if this variable is set and only do the rest of the function if yes. I don't know if this makes any sense but as the dimer method nevertheless just does strange things I suppose it does not matter that much.

[S0S-90]

It still happens sometimes but it seems much more rarely. The vector that was zero was s0.g and I think it is created in function coords::Main_Callback::operator() in file coords.cc so if someone wants to do something about this error it might be a good idea to take a closer look at this function.