Fix typo (#560)

CHANGES/v2.2.md

@@ -115,7 +115,7 @@ Version 2.2.2 (Apr 13, 2016)
 
 For users:
 - \ref MOLINFO for RNA accepts more residue names, see \issue{180}.
-- added two mpi barries (one was missing in PBMetaD for multiple walkers) to help syncronise initialisation
+- added two mpi barries (one was missing in PBMetaD for multiple walkers) to help synchronized initialisation
 - Fixed a bug in internal stopwatches that was making \ref DEBUG logRequestedAtoms not working
 - Some multicolvars (including \ref BRIDGE, \ref ANGLES, and \ref INPLANEDISTANCES) now crashes if one
   asks for too many atoms, see \issue{185}.

CHANGES/v2.5.md

@@ -144,7 +144,7 @@ Changes from version 2.4 which are relevant for developers:
 - It is not possible anymore to use `make install prefix=/path`. Prefix can only be changed during `./configure` (see \issue{332}).
 - Exception class has been rewritten to allow more extensive messages. Now also function name is shown.
 - On linux, library is linked with `-Bsymbolic`.
-- When launching `plumed`, flags `--no-mpi` and `--mpi` can appear multiple times. The last appearence is the effective one.
+- When launching `plumed`, flags `--no-mpi` and `--mpi` can appear multiple times. The last appearance is the effective one.
 - Internal BLAS and LAPACK libraries updated to gromacs 2018.
 - Choosing `./configure --prefix=$PWD` does not lead anymore to deletion of all header files.
 - A copy of `plumed-runtime` is installed in `prefix/lib/plumed` and can be used for testing.

astyle/src/ASFormatter.cpp

@@ -4164,7 +4164,7 @@ void ASFormatter::formatPointerOrReferenceToType()
 			break;
 		}
 	}
-	// append the seqence
+	// append the sequence
 	string charSave;
 	size_t prevCh = formattedLine.find_last_not_of(" \t");
 	if (prevCh < formattedLine.length())

developer-doc/AddingAFunction.md

@@ -67,7 +67,7 @@ do this can be found here: \ref usingDoxygen
 }
 
 FunctionNAME::FunctionNAME(const ActionOptions&ao):
-/--- These two lines set up various things in the plumed core whcih functions rely on.
+/--- These two lines set up various things in the plumed core which functions rely on.
 Action(ao),
 Function(ao)
 {

developer-doc/AddingAMeasure.md

@@ -2,7 +2,7 @@
 
 To implement a new method for calculating the distance between a pair of trajectory frames you will need to work with the
 PLMD::reference module.  This module is used in many parts of PLUMED (e.g. path collective variables, field-cvs and analysis methods).
-Consequently, if you implment your distance measure using the functionality in this class you will be able to use it in a 
+Consequently, if you implement your distance measure using the functionality in this class you will be able to use it in a 
 wide variety of difffernt contexts.  As always if you would like us to incorporate your measure in the release version of 
 PLUMED you will need to write at least one regression test for it.  Details on how to write regression tests are provided 
 here: \ref regtests  
@@ -47,7 +47,7 @@ to include the MetricRegister.h file and the following line:
 PLUMED_REGISTER_METRIC(OptimalRMSD,"OPTIMAL")
 \endverbatim
 
-Once again dynamic polymorphism is exploited agin here.  With this example the command above ensures that PLMD::OptimalRMSD objects
+Once again dynamic polymorphism is exploited again here.  With this example the command above ensures that PLMD::OptimalRMSD objects
 are used whenever the command METRIC=OPTIMAL is found in the PLUMED input.
 
 Your new class must contain a constructor, a method to read in the configuration from a pdb file (read) and a method to calculate

developer-doc/AddingAMultColvar.md

@@ -4,7 +4,7 @@ As you are no doubt aware within plumed 2 you can calculate multiple
 instances of a collective coorinate from a single line in the input file.
 One can then calculate functions such as the minimum, number less than,...
 from the resulting distribution of collective variables.  To create these kinds
-of collective variables we use the functionality implmented in PLMD::multicolvar::MultiColvar.
+of collective variables we use the functionality implemented in PLMD::multicolvar::MultiColvar.
 In fact in writing a single PLMD::multicolvar::MultiColvar you actually write many CVs at once
 as the minimum of a distribution, the number less than and so on come with no 
 additional effort on your part.
@@ -141,9 +141,9 @@ PLMD::multicolvar::Distances
 \verbatim
 keys.add("atoms-1","GROUP","Calculate the distance between each distinct pair of atoms in the group");
 keys.add("atoms-2","GROUPA","Calculate the distances between all the atoms in GROUPA and all "
-                            "the atoms in GROUPB. This must be used in conjuction with GROUPB.");
+                            "the atoms in GROUPB. This must be used in conjunction with GROUPB.");
 keys.add("atoms-2","GROUPB","Calculate the distances between all the atoms in GROUPA and all the atoms "
-                            "in GROUPB. This must be used in conjuction with GROUPA.");
+                            "in GROUPB. This must be used in conjunction with GROUPA.");
 \endverbatim
 
 To be clear, if these keywords are registered the actual readin of the atoms is looked after by the method
@@ -156,10 +156,10 @@ register keywords in PLMD::multicolvar::Angles:
 \verbatim
 keys.add("atoms-1","GROUP","Calculate angles for each distinct set of three atoms in the group");
 keys.add("atoms-2","GROUPA","A group of central atoms about which angles should be calculated");
-keys.add("atoms-2","GROUPB","When used in conjuction with GROUPA this keyword instructs plumed "
+keys.add("atoms-2","GROUPB","When used in conjunction with GROUPA this keyword instructs plumed "
                             "to calculate all distinct angles involving one atom from GROUPA "
                             "and two atoms from GROUPB. The atom from GROUPA is the central atom.");
-keys.add("atoms-3","GROUPC","This must be used in conjuction with GROUPA and GROUPB.  All angles "
+keys.add("atoms-3","GROUPC","This must be used in conjunction with GROUPA and GROUPB.  All angles "
                             "involving one atom from GROUPA, one atom from GROUPB and one atom from "
                             "GROUPC are calculated. The GROUPA atoms are assumed to be the central "
                             "atoms");
@@ -178,7 +178,7 @@ sets of routines may be useful:
 <td width=10%> PLMD::multicolvar::MultiColvar::readTwoGroups </td> <td> This is used to read in the GROUPA and GROUPB keywords.  When you use this funciton you can change GROUPA and GROUPB to whatever you desire </td>
 </tr> <tr>
 <td width=10%> PLMD::multicolvar::MultiColvar::readThreeGroups </td> <td> This is used to read in the GROUPA, GROUPB and GROUPC keywords. 
-                                                                          When you use this funciton you can change GROUPA, GROUPB and GROUPC to whatever you desire.  
+                                                                          When you use this function you can change GROUPA, GROUPB and GROUPC to whatever you desire.
                                                                           For an example see PLMD::multicolvar::Bridge </td>
 </tr> <tr>
 <td width=10%> PLMD::multicolvar::MultiColvar::readSpeciesKeyword </td> <td> This is used to read in SPECIESA and SPECIESB keywords.  Once again you can use this funciton and use different keywords. </td>
@@ -222,7 +222,7 @@ This code does three things:
 - It reads in all the keywords that are specific to your new CV.  In this case it is a switching function that is read by parse("SWITCH",sw).
 - It reads in the atoms involved in the CV.  In this case this is all looked after by the base class method PLMD::multicolvar::MultiColvar::readAtoms
 - It sets the cutoff for link cells by exploiting the method PLMD::multicolvar::MultiColvarBase::setLinkCellCutoff.  This is really important - your code will run much faster if you exploit link cells. 
-- It checks that readin was succesful.  This is the final call to checkRead
+- It checks that readin was successful.  This is the final call to checkRead
 
 Within the constructor of a multicolvar there must be a call to PLMD::multicolvar::MultiColvar::readAtoms even if you choose to read in the atoms using
 one of the methods described in the table above.  

developer-doc/AddingAnAnalysis.md

@@ -179,7 +179,7 @@ As such in PLMD::dimred::DimensionalityReductionBase and its daughter classes we
 The dissimilarities between the input high dimensional frames will always be calculated by some method akin to PLMD::analysis::EuclideanDissimilarityMatrix.  
 PLMD::dimred::DimensionalityReductionBase inherits from PLMD::analysis::AnalysisBase and expects another PLMD::analysis::AnalysisBase object as input.  
 Furthermore, with the exception of PLMD::dimred::ClassicalMultiDimensionalScaling the input PLMD::AnalysisBase must be an 
-PLMD::dimred::DimensionalityReductionBase as initial guesses must be suggested when using an interative optimization algorithm such as PLMD::dimred::SMACOF.
+PLMD::dimred::DimensionalityReductionBase as initial guesses must be suggested when using an iterative optimization algorithm such as PLMD::dimred::SMACOF.
 
 Much of the work of dimensionality reduction done in the base PLMD::dimred::DimensionalityReductionBase class.  When implementing any new
 dimensionality reduction algorithm your focus will be on writing a PLMD::dimred::calculateProjections routines.  This function will take as

developer-doc/AddingRegressionTests.md

@@ -56,7 +56,7 @@ type=simplemd tells PLUMED that the test will involve
 running some Lennard Jones MD using <a href="../../user-doc/html/simplemd.html">simplemd</a>, 
 type=sum_hills tells PLUMED that the test will involve summing gaussians using the 
 <a href="../../user-doc/html/sum_hills.html">sum_hills</a> untility
- and type=make tells PLUMED that a main function (called main.cpp) is included in the regtest directory and that the test should compile this fuction, link in 
+ and type=make tells PLUMED that a main function (called main.cpp) is included in the regtest directory and that the test should compile this function, link in
 the PLUMED library and run the resulting executible. The vast majority of features are best tested using type=driver here although the type=make function
 can be useful for testing tools that are used in many places in the code (see the code in regtest/basic/rt-make-4 for an example of how use type=make to test
 PLUMED's internal matrix class).  If you need to test PLUMED in a way that is not included in these various types please contact the PLUMED developers before
@@ -73,7 +73,7 @@ run is thus as follows:
 plumed driver --plumed plumed.dat --trajectory-stride 50 --timestep 0.005 --ixyz diala_traj_nm.xyz --dump-forces forces --dump-forces-fmt=%10.6f
 \endverbatim    
 
-- The final line tells PLUMED that a few files need to be copied from elsewhere in the PLUMED directory heirarchy in order to run the test.  This copying of files
+- The final line tells PLUMED that a few files need to be copied from elsewhere in the PLUMED directory hierarchy in order to run the test.  This copying of files
 is useful as it ensures that our repository does not grow large because the same trajectory is duplicated in many regtest directory.  However, if all the files you 
 need to run the test  are contained in the test directory this line is not necessary.  Having said that, however, it may be useful to reuse the trajectories contained 
 in the directory regtest/trajectories in creating your own regression tests.  

developer-doc/HowToContributeToPlumed.md

@@ -25,7 +25,7 @@ wrote the functionalities they are using and not to simply assume that we (the c
 everything in PLUMED.  
 - The author of any feature is responsible for ensuring their feature is maintained in perpetuity.  
 That is to say we (the core developers) will not take responsibility for maintaining features that we
-did not ourselves write.  Furthermore, this maintenence involves answering users questions on the mail
+did not ourselves write.  Furthermore, this maintenance involves answering users questions on the mail
 lists as well as the occasional fix to the relevant cpp files.
 
 In addition, to these two requirements we do not want the core-developer team to expand as we believe that
@@ -116,7 +116,7 @@ include ../maketools/make.module
 You should only need to modify the first line of this file - the line starting with USE=.  This line is used to tell PLUMED at compile time
 what other modules are required in order for this module to function.  This module relies on functionality that is contained in the core, tools, 
 vesselbase and multicolvar modules and so these modules are all required during compilation of this particular module.  For your new module you 
-will most likely always need to use core and tools.  The other modules that are required will depend on what you are implemening. 
+will most likely always need to use core and tools.  The other modules that are required will depend on what you are implementing.
 
 The last thing you will need to do before you start programming is that you will need to modify the .gitignore file in the src directory in order 
 to stop git from ignoring your new module directory.   If you look in the .gitignore file you will see that it reads something like this:

developer-doc/InstallationLayout.md

@@ -35,7 +35,7 @@ most of the plumed-related files. Similarly, from C++ you can use \ref config::g
 the same path.
 
 When a plumed command line tool implemented as script is invoked by the plumed executable,
-thus transfering the control from C++ to
+thus transferring the control from C++ to
 an external script, the environment should be consistently set. This is done in method \ref config::getEnvCommand()
 which builds a string in the form `env PLUMED_ROOT=/path env PLUMED_INCLUDEDIR=/path ` etc.
 In this ways, the scripts are run in an environment with the correct settings.

developer-doc/Intro.md

@@ -4,7 +4,7 @@ This is the developer manual. Please first have a look at the <a href="../../use
 
 Plumed 2 is written in C++ and uses many of the advanced, object-oriented features of this language.  This structure makes the implementation of collective coordinates and free energy methods straightforward.  In fact, it should be possible to implement methods and collective coordinates (CV) by creating a single file and without touching any other part of the code. Futhermore, to implement new methodology does not require one to be some sort of C++ wizzard. Rather, the code has been specifically redisigned to make the implementation of new CVs and new free energy methods straightforward so as to encourage people to implement whatever new functionality they require.  This document serves then to provide an introduction as to how to go about implementing new functionality in plumed. A good starting point is \ref INHERIT as this page contains links to parts of the manual where you can find information on how to go about implementing CV, functions and biases. Another useful page is the \subpage TOOLBOX page, which contains information on the many reusable objects that have been implemented in plumed.  
 
-If you want to understand a little more about the code and the way that we use the various features of C++ before you start then we describe this breifly here:   
+If you want to understand a little more about the code and the way that we use the various features of C++ before you start then we describe this briefly here:
 
 \ref ABriefIntroduction 
 
@@ -64,7 +64,7 @@ To add a class to this group, just put a
 \verbatim
 \ingroup MULTIINHERIT 
 \endverbatim
-statement somwhere inside the header.
+statement somewhere inside the header.
 @}
 
 \defgroup INHERIT Base classes for CVs, functions, biases, etc.