I removed the sentence saying that 2.2 will crash.

We should likely make it fail on travis-ci so that
we remember to add the documentation, but I cannot
do it know as one regtest basic/rt44b in v2.2
would fail.

This functionality is not complete.  In multicolvar this is
done correctly.  However, for normal colvars and the like
derivatives are still calculated even when they are not required

All components now have to be registered in registerKeywords so that
documentation on what componets are available in a given action are
available in the manual.  Currently the code gives a warning if a user
tries to use a component that is not properly described in the manual.
In the future (v2.2) this warning will be replaced by an error.  That
is to say you wont be allowed to use unregistered components.  This is
all described more in #76

I set it to 2 instead of 2.0, so that it will not be necessary
to update it

Speeds up RMSD quite a bit with -DNDEBUG

If you want to but a plumed_assert in a loop you should now use
plumed_dbg_assert / plumed_dbg_massert.  This will not be included
in the code if you compile with -DNDEBUG

I replaced all the "using namespace PLMD" statements with explicit
namespace PLMD{ …… }. This is more clear and simplify the syntax for
defining operators

All the source code have been moved into subdirectories of src/
Some of these subdirectories are treated in a special manner:
src/wrapper contains the wrappers for MD codes
src/main contains the main.cpp file
src/config contains files generated without compilation,
  just based on configuration info
src/lib is the place where executables and libraries are put
  at the end
src/cltools contains the command line tools
src/tools contains plumed tools (reusable classes)
src/basic contains PlumedMain, Action hierarchy and other basic stuff
src/multicolvar contains MultiColvar stuff
src/imd is the interactive MD (still not totally portable).

Notice that, to allow easy inclusion of .h files from other modules,
I link all the directories in src/ into module directory. In this
way it is possible e.g. to write #include "config/PlumedConfig.h"

See src/README and src/basic/Makefile to understand how inter-module
dependencies are set

Periodicities of values are stored as strings inside Values.
These strings are output as constant fields inside the colvar and
hills files.  In addition the fact that we now use strings means that
when you have a function and you have to specify its periodicity you can
use PERIOD=-1.5pi,1.5pi or some other thing like that

as suggested by Gareth

I added a PEOPLE file containing list of authors and a script
(src/header.sh) which applies the Licence to all the source files.

It can be applies multiple times (it automatically deletes the present header
and replace it with the new one). Thus, to change the header, edit header.sh
and execute it.

Added funcitonality so that one can restart field cv calculations
Added field cvs for contact maps

Many checks on size() transformed in checks on empty()
(suggested by cppcheck)

Changed the way values work so that the ActionWIthVaule pointer is
inside

independent of ActionWithValue.  That is to say there is no
longer a reference to an ActionWithValue object inside Value
objects.  I also changed many of the names of routines inside
ActionWithValue. This is to try and make this class as transparent
as possible to the end user.  There is also extensive documentation
for ActionWithValue

this will appear in the manual

should not call the Action::registerKeyword stuff.

Indeed, since we stay on multiple inheritance, Action the keywords
should be added by the daughter classes

Added keyword registering functions to Action, ActionWithValue, ActionWithArguments and ActionSetup.
Also added variables so that the keyword list can be passed to the Actions

(merged from gat2-reorder branch)

Added keyword registering to all the action classes listed below

(merged from gat2-reorder branch)

Added register keywords functions to all the classes below
(merged from gat2-reorder branch)

Fixed the registerKeywords routines in the committed subroutines

Made sure colvar is adding keywords for numerical derivatives

Oops... genericDebug should register keywords for action pilot.  It does now

Added keyword registering for moving restraint

Added keyword registering for NATURAL keyword

COMPONENTS should have been registered as a flag and not an optional oops

I replaced many of the "low level" assertions, trying to add messages here and there.
Still, this is mostly for developers: errors in the input file should get better reports.

I forbid Actions to declare both an unnamed value and named values.
In a far future, the action name alone will imply passing the full structure.
Example:
d1: DISTANCE ATOMS=1,2 COMPONENTS
now only declared d1.x d1.y and d1.z, whereas d1 cannot be accessed
directly as a value (since it is a complex structure that we cannot handle
yet)

There is a new method for colvars and function, enforceNumericalDerivatives(),
which can be used in the constructor so as to enforce numerical derivatives.
It should be added to complex colvars for which we do not want to implement
numerical derivatives, or can be used at preliminary stage during CV
implementation.

I also added a check for colvar ENERGY, which cannot be done with
numerical derivatives

Implementation is rather general and allows one to use them not only for debugging but also for real calculation. A keyword NUMERICAL_DERIVATIVES can be used in directives such as COLVARs or FUNCTIONs, and automatically performs numerical derivatives instead of analytical ones. Moreover, I added a DUMPDERIVATIVES directive which prints on a file the derivatives of the (ARG) colvars. E.g.:
DISTANCE LABEL=C1 ATOMS=0,1 COMPONENTS
DISTANCE LABEL=C1n ATOMS=0,1 COMPONENTS NUMERICAL_DERIVATIVES
DUMPDERIVATIVES ARG=C1,C1n FILE=derivC1
will define two CVs, with the same value, but one with analytical and the other with numerical derivatives, and will write two columns on file "derivC1" with the derivatives, which can be compared for debugging.

BE CAREFUL: I did not test it with non-orthorombic cells, there may be problems in the virial components

This is the draft version that I prepared and that we will use as
a starting point. Still it is a bit dirty, and I will try to improve
documentation and delete unused routines