This is associated with the fix of VOLUME derivatives

They were not implemented. A separate colvar (CELL) is coming soon

Notice that now it is also possible to use VOLUME with NUMERICAL_DERIVATIVES
(so as to debug). I tested with NPT and a box of water and seems to work correctly.

(From Paolo Raiteri)

This bug only appears when you store information so for things like moments
and proper multicolvar functions as opposed to Region, which is a fake
multicolvar function

Thanks to Paolo Raiteri

Seems to work with a simple example.
Use with care: not very tested yet!

It is more flexible since it allows adding new files instead of just patching

An MD engine could have no patch, and do everything with scripting

Links to used modules are made automatically by Make. They should not be saved in
the git repository. I think I already fixed this, but maybe it was not properly
committed

I converted from xyz to gro a regtest where boxes of different
shapes were used. This is to verify that box reading (with --igro)
and writing (with DUMPATOMS) is consistent.

If MOLINFO are available they are used in the resulting gro file.
Filetype is detected automatically, but can be enforced.
Atomnames are also written in xyz files.

ENDPLUMED was not correctly understood

File was open in a manner that do not provide autobck

Now all multicolvars can have a central atom position and can be used in
multicolvar functions.  This makes the code a bit clearer.  Also secondarystructure
variables are now faster as much copying of derivatives is removed.

Some files that are automatically generated were mistakenly added to git repository

This makes these two classes slightly simpler.  It also allows one to
use MultiColvarFunctions on MultiColvarFunctions.  We can thus do things
like the value of the dot product of the q4 vector on a atom with the
q4 vectors on the atoms in the first coordination sphere averaged over a
subregion of the simulation box.

At the moment this can only be used to place a wall around a cluster
so that the atoms stay within a bubble centred on the centre of mass

ActionWithVessel is calculating sums.  For many of the quantities
ActionWithVessl calculates (e.g. less_than, more_than, coordination numbers )
each of the terms in the sum is a number between zero and one. A reasonable
way to implement the neighbor list is to ignore terms less than
a small number (TOL) at every step.  On neighbor list update steps we recalculate
all the contributions to the sums.  Anything less than NL_TOL (a number less
than TOL) can safely be ignored until the next neighbor list update step.
For complex variables (e.g. q6) a considerable speedup can be acchieved just by
setting the value of TOL.  However, for variables such as coordinationnumbers,
where calculating all the distances is the most expensive part of the calculation,
the neighbor list and a TOL value are required to get the code to run fast

Something wrong could happen to inc files depending on the order in which they are produced

On machine without dynamic libraries, just leave "SOEXT"
undefined in the Makefile.conf. Compilation of dynamic libraries
will be skipped.

I also fixed the src/lib/Makefile such that I am sure that no .so
object is generated for machines where SOEXT is undefined

Avoid recalculation of shifts at every CV

I took advantage of the fact that we have the reduced cell. This
allows to avoid the comparison of different shifts for
many values of the scaled coordinates, as well as using the
sign of the scaled coordinates to check which shifts should
be attempted. The average number of shift vector to be evaluated
is approximately 1 (plus the "null-shift")

There is also a Pbc::test() function which I used during debugging.
I leave it there for future reference.