Frequently Asked Questions
Some of the most common questions which arose among the users are listed below. To display the corresponding answers, please click on the relevant question or statement.
Sorting potential problems
As indicated in the manual and the readme file, ProtoMS has certain dependencies. You will need a fortran compiler, having python and cmake installed for the ProtoMS installation to be successful.
The most challenging aspect to get in place for compilation can be the MPI libraries. During the execution of cmake you may see the message ""Could NOT find MPI_Fortran (missing: MPI_Fortran_LIBRARIES MPI_Fortran_INCLUDE_PATH)". When you run cmake it attempts to find the correct MPI libraries to use them in compiling the executable. If you see this message then either a suitable MPI version is not installed or it is installed in a non-standard location. On shared research environments it is not uncommon for multiple MPI versions to be available or none at all. Problems can arise at two different points, compilation of the code or execution of the resultant protoms3 binary. Compilation - this manifests during the execution of the cmake command with the output "Could NOT find MPI_Fortran (missing: MPI_Fortran_LIBRARIES MPI_Fortran_INCLUDE_PATH)". In this case cmake was not able to
A test suite is provided with the latest version of ProtoMS. This can be useful for both end users and developers.
End users may want to test whether the compilation of ProtoMS has produced the correct output. Developers will most likely want to check that their changes to the code have not broken previous functionalities. Both these checks can be performed with the test suite. Information on how to run the test suite can be found in the "Test Suite" section of the Manual.
A number of errors are handled within the ProtoMS tools and protoms.py, producing useful error information. First of all, try looking at the error message produced. Take a look below in case the error message was not useful.
Make sure all the dependencies for the ProtoMS tools are installed. As mentioned in the manual and readme file, these include Python version 2.7, the Python modules NumPy, ScyPy and Matplotlib, as well as AmberTools. An extra dependency, pymbar, is optional and will allow for free energy calculations with the MBAR methodology.
Here you can find listed some of the most common cases why simulations do not work, and the solution, while simple, might be slightly obscure.
It is important to remember that the file name of your .cmd file must be all in lower case.
ProtoMS cannot deal well with files (such as protein pdb files, solutes templates, etc.) when they are indicated in the .cmd file with long paths / file names. The use of absolute paths is the most common reason for this problem to arise. Please, consider the use of relative paths.
Below, some of the most common warnings are briefly explained. A list of all possible warnings is not available in the website at the moment. If you encounter an obscure warning which is not displayed below, we suggest you look in the code where that warning appears to understand what it refers to (i.e. with the "grep" command). If further help is needed, feel free to drop us an email.
This line indicates that something did not proceed as expected with the simulation. The previous line in the warning file generally provides information on the exact problem. Common associated issues are related to incorrect paths to the template or pdb files specified in the .cmd file
Uh-oh! This version of the code does not yet support the building
of missing solute atoms! This feature is planned though...
This should be associated with one of the warning lines displayed just above. Equally, the simulation is not proceeding as expected.
ProtoMS has a problem dealing with atom names starting with a number. Protonation of ligands with some programs (such as UCSF Chimera) will generate hydrogen names which first character is a number. Please, make sure to change those before proceeding.
These lines indicate the presence of overlapping parameters in the parameter files provided in the .cmd file. Each given parameter is specified in the warning line.
In most cases this warning is an indication of normal behaviour: i.e. the "overwriting" of a default GAFF parameter for a small molecule with that provided in the template file. When following the automatic set-up tools, this warning can generally be disregarded. However, in particular situations this warning can provide useful insight in problems with the simulation. Hence, it should be carefully taken into account if template files for small molecules have been generated manually, or if the parameter files provided in the .cmd file have been modified / chosen manually.
This warning does require a little explanation. Internally, ProtoMS requires all possible atoms (including all possible hydrogens) on a given residue to be present. Since this is generally not the case for certain residues (i.e. Glu and Asp), ProtoMS automatically generates Dummy atoms to take their positions. These will, however, have no influence in the simulation (all their energies are switched off), they are simply required for ProtoMS to run.
Hence, even if it may sound counterintuitive, if the specific atom should not be there in the simulation, this line is perfectly acceptable. However, if this refers to residues which cannot hold further atoms besides those which are defined in your protein pdb (i.e. neutral, non-terminal residues), this generally indicates a problem related to hydrogen naming. For these cases, try using the tool convertatomnames.py on your protein or scoop. If this does not solve your problem, you try to convert your protein to Amber naming before applying our atom name conversion.
This warning appears on the normal behaviour of scoops in ProtoMS. While it is a relevant warning, and indeed those residues should be kept fixed (or at least their backbone should), this is handled appropriately by the set-up tools. You may want to make sure that those residues are included in the "fixresidue" or "fixbackbone" chunk (which might be in your .cmd or protein pdb file). However, if the automatic set-up was followed, all should be correct.
Currently ProtoMS cannot deal with cystein bridges flexibility. Hence, please make sure that, in case your protein includes a cystein bridge, both cystein residues, as well as the residues immediately surrounding the cystein bridge are fixed in your protein. Look at the manual if you need help with this.
Understanding why
Monte Carlo and Molecular Dynamics are two different methods of sampling the configurational and energetic landscape of a system. While both techniques sample the same phase space, their sampling efficiencies may not be equal. Consequently while in a hypothetical infinite simulation, the results should be independent of the sampling methodology, for a given computational time, results might differ.
While conceptually, Monte Carlo(MC) is an efficient sampling method, considerably less efforts have been invested in its optimization and parallelization compared with Molecular Dynamics(MD). Consequently, the most modern MD codes will generally beat their MC counterparts in sampling efficiency.
Protein conformational changes are a representative example of the differences that might be expected between MD and MC sampling outcomes. When a given protein has several stable (low energy) configurations which differ in the overall position of a protein structure element (i.e. α-helix, or loop), these conformations should not be expected to interconvert throughout a explicit solvent MC simulation. This may provide advantages if, say, differences in free energy between the two conformations are to be calculated; while being an inconvenient for general conformational sampling.
In summary, conformational sampling in MC tends to be more restricted to local minima than that of state of the art MD, within feasible computational time.
Scoops are spherical sections of the protein, commonly centred around its ligand or binding cavity, which are passed to ProtoMS to simulate instead of the whole protein. The spheres of water account for the solvation around the (commonly scooped) protein. In ProtoMS the use of both these options is highly recommended. This is necessarily related to the boundary conditions used throughout the simulation.
The main reason behind the use of spheres (instead of boxes) of water, as well as scooping the protein is the reduction in computational expense. As it is mentioned in the previous question, Monte Carlo lacks on investment to optimize the performance in terms of sampling efficiency. Hence, saving in computational expense is definitely worth the time difference. However ProtoMS can equally handle a full protein in a box of waters, simply the computational time required for the same amount of moves will be considerably higher.
In ProtoMS, several ensembles can be simulated, but the two most common ones are NPT and NVT. When dealing with a small molecule in water (i.e. calculating hydration free energies), the system is generally defined as a box of water with the ligand in the middle. Periodic boundary conditions are applied, and the ensemble simulated is NPT. However, when a protein is involved, simulations tend to get a lot more computationally expensive. Hence, the solvation is generally represented by a sphere of water, and the simulated ensemble is now NVT.
A protein scoop is defined by the outer and the outer region. As the scoop is generated, the flexibility that each of these regions will have during the simulation can be customized. As most things, the decided size of a scoop is a trade-off between computational expense and representativity of the simulated system. The defaults given in the set-up tools are a good starting point.
Just like in the scooping region, the dimensions of the sphere of water are a compromise between the accuracy of the interactions captured and computational time. Again we recommend the values provided throughout the automatic set-up.
As it has been hinted in the previous question, increasing the speed of the simulation will generally be involved in a trade-off with decreasing its accuracy. This can, at times, be a perfectly valid approach, since approximations made elsewhere in the computational method may make this new loss in accuracy irrelevant.
In terms of solvent optimization, the latest version of ProtoMS includes optimized version of the tip3p and tip4p water models. These can be switched off within the solvent parameter files. However, we highly recommend to use them in any case possible.
History of ProtoMS
The original idea and development of ProtoMS were the result of C.J. Woods coding efforts in early 2002. Originally named ProtoMC, the naming of the software reflects the code was created to provide the means to prototype new Monte Carlo simulations.
Sire originated from ProtoMS.
ProtoMS is written in Fortran. However during 2005 a new version of the software, rewritten in C++/Python, was produced by C.J. Woods. It was eventually released in 2007 under the name of Sire.
ProtoMS was a commonly used and relevant software, but usability was an issue.
ProtoMS3.0 was released by the end of 2014 to address this issue. It is the joint effort of five developers (namely S. Genheden, R. Bradshaw, G. Ross, C. Cave-Ayland and A.I. Cabedo Martinez). The usability of the Fortran code was improved, and a homogeneized set of tools was generated and released as part of the software.
ProtoMS1.0 (released 2002) and ProtoMS2.0 (released 2003) were fully managed by C.J. Woods.
ProtoMS2.1 was the first version to be released publicly, in 2006. J. Michel and C.J. Woods are resposible for this release.
ProtoMS2.2 was fully managed by J. Michel, released in 2007.
All information on the Previous Versions ProtoMS repository was deposited from September 2009.
ProtoMS2.3 was released in 2012, including work from many contributors, managed by C.J. Woods and J. Michel.
ProtoMS2.4 (released in 2013) was managed by S. Genheden.
All ProtoMS 3.X releases were coordinated as a joint effort of the development team (Genheden, Bradshaw, Ross, Cave-Ayland, and Cabedo Martinez, with Graham joining from 3.1). Main contributions specified below refer to the main resposible for new functionalities added to the code.
ProtoMS3.0 (released in 2014) was the joint effort of S. Genheden, R. Bradshaw, G. Ross, C. Cave-Ayland and A.I. Cabedo Martinez.
ProtoMS3.1, released in 2015, has main contributions from S. Genheden, A.I. Cabedo Martinez and J. Graham.
ProtoMS3.2, released in 2016, has main contributions from G. Ross, A.I. Cabedo Martinez and J. Graham.
ProtoMS3.3, released in 2017, has main contributions from G. Ross, H. Bruce Macdonald, C. Cave-Ayland, J. Graham
ProtoMS3.4, released in 2017, has main contributions from H. Bruce Macdonald, C. Cave-Ayland, M. Samways
In case your particular question is not listed above, feel free to contact us on this email.
Current version of ProtoMS 3.4.0