Git Product home page Git Product logo

colvars / colvars Goto Github PK

View Code? Open in Web Editor NEW
185.0 18.0 52.0 42.38 MB

Collective variables library for molecular simulation and analysis programs

Home Page: http://colvars.github.io/

License: GNU Lesser General Public License v3.0

Makefile 0.27% C++ 75.66% Tcl 9.75% Python 4.44% Shell 4.23% Awk 0.07% C 0.06% Perl 1.30% TeX 0.13% M4 0.05% Rich Text Format 2.81% CMake 1.06% Raku 0.15% Fortran 0.02%
simulation molecular-dynamics free-energy namd vmd lammps enhanced-sampling gromacs tinkerhp collective-variables

colvars's Introduction

Collective variables module (Colvars)

A software library for molecular simulation and analysis that provides a high-performance implementation of sampling algorithms defined on a reduced space of continuously differentiable functions (aka collective variables).

First released in 2008 as part of the standard distribution of NAMD version 2.7b1, Colvars has also been integrated in LAMMPS, VMD, GROMACS, and Tinker-HP. In VMD, interactive use is possible both from the command line and through the Dashboard graphical user interface.

The functionality provided to those packages by Colvars includes a variety of functions and algorithms, including free-energy estimators based on thermodynamic forces, non-equilibrium work and probability distributions.

Obtaining and using

The easiest way to obtain pre-compiled versions of Colvars is via one of the following software packages:

Please check here to see which version of Colvars is included with the round-number or "stable" versions of each code.

Documentation

The Colvars webpage includes user documentation for all codes, as well as a Doxygen-based developer documentation.

To reflect the different availability of features in each engine, the Colvars reference manual comes in several flavors: GROMACS LAMMPS NAMD Tinker-HP VMD

Citing

The reference article is: G. Fiorin, M. L. Klein, and J. Hénin, Mol. Phys. 111 (22-23), 3345-3362 (2013). https://doi.org/10.1080/00268976.2013.813594 [BibTex file] [Endnote file]

Additional references for the implementation of specific features are listed in the documentation. Beginning with Colvars 2021-08-30, these references, including acknowledgments of specific code from the MD engine, are also printed to the screen/logfile when they are used.

Note to NAMD users: the NAMD reference papers (Phillips et al, 2005 and 2020) are used in some publications to acknowledge Colvars features. This is incomplete. When possible, please consider identifying and acknowledging all development efforts that supported your project. As an important clarification, most of the Colvars code was developed outside of the NAMD/VMD funding grants.

Example input

Colvars requires a configuration file, or alternatively configuration arguments given through scripting commands by the linked program.

  • In NAMD:
colvars on
cv configfile <Colvars configuration file>
  • In VMD (Tip: try also the new "Colvars Dashboard" plugin):
cv molid top
cv configfile <Colvars configuration file>
  • In LAMMPS:
fix Colvars all colvars configfile <Colvars configuration file>
  • In GROMACS 2024 and later (mdp file):
colvars-active = yes
colvars-configfile = my_config.colvars
  • In Tinker-HP: Create a Colvars configuration file with the same prefix as the .key file, and the extension .colvars.

The contents of the configuration file are typically the same across all programs, for example:

colvar { # Define a new variable
  name d # Must give a name to this variable
  width 0.2 # Estimated fluctuation amplitude and/or grid resolution, "w_d"
  distance { # This variable is a distance between centers of mass (COMs)
    group1 { atomNumbers 1 2 3 } # List the atoms of the 1st group
    group2 { atomNumbers 4 5 6 } # List the atoms of the 2nd group
  }
}

harmonic { # Define a harmonic potential, 1/2*K*(d-d0)^2/w_d^2
  colvars d # Apply it to the variable "d"
  centers 5.0 # The center of the potential, "d0"
  forceConstant 10.0 # Force constant, "K"
}

Complete input decks for some of the most commonly used features are available in the examples repository: https://github.com/Colvars/examples

See also the examples folder of this repository for other examples of configurations. Configuration options (particularly, the selections of atoms) require minimal changes to reflect the specifics of each simulation.

The tests folder also contains functional segments of Colvars configuration, used to build numerical tests of code accuracy and stability. Feel free to use these segments in your production runs.

Updating to the latest version

To recompile each program with the most recent version of the library, download the master branch of this repository, or clone it via git:

git clone https://github.com/Colvars/colvars.git

and run the provided update-colvars-code.sh script against the unpacked source tree of any of the supported programs:

./update-colvars-code.sh /path/to/lammps           ; # updates LAMMPS
./update-colvars-code.sh /path/to/NAMD_X.YY_Source ; # updates NAMD
./update-colvars-code.sh /path/to/vmd-X.Y.Z        ; # updates VMD
./update-colvars-code.sh /path/to/vmd-plugins      ; # updates VMD plugins
./update-colvars-code.sh /path/to/gromacs-XXX.X    ; # update GROMACS

and recompile them.

The update-colvars-code.sh script support patching the latest development version of each program:

All of the above MD engine versions are automatically tested as part of GitHub Actions workflows.

Legacy GROMACS-Colvars patched releases

Versions GROMACS prior to 2024 are supported through the use of a customized mdrun command line; source code of these patched releases is available here. When posting a message to the Gromacs forum regarding the use of these patched releases, please specify "GROMACS modification: Yes".

Which version of Colvars is recommended?

The Git master branch is to be considered the "stable" release at any given time; any bugfixes are released through master first. The input syntax is near-completely backward-compatible and output files are forward-compatible. Feel free to download Colvars and update GROMACS, LAMMPS, NAMD, Tinker-HP or VMD as needed.

Other branches are dedicated to the development of specific features: please use them at your own discretion.

Which version of Colvars is included in package XX version YY?

The specific version of Colvars is identified both in the code and in the documentation by the date of the most recent code revision (e.g. 2021-01-19). This date is printed to the standard output or log file as soon as Colvars is activated.

A table mapping software package release versions to Colvars versions is given here.

If you are using a stable release of any of the codes mentioned above, feel free to use the version number of that code when asking questions.

Feedback

For usage questions, please start a new Discussion.

For bug reports or feature requests, use the "Issues" tab.

License

This software is distributed under the GNU Lesser General Public License version 3 (LGPLv3); see the file COPYING.LESSER for complete licensing terms.

In the interest of broad distribution, copies of this code are also included in GROMACS (LGPLv2), LAMMPS (LGPLv2), NAMD and VMD (UIUC license); however, the terms of the LGPLv3 still apply to code originating from this repository.

colvars's People

Contributors

akohlmey avatar alejob avatar e-kwsm avatar fabsugar avatar fhh2626 avatar giacomofiorin avatar hanatok avatar hublot avatar jeffcomer avatar jewettaij avatar jhenin avatar jvermaas avatar mvondomaros avatar renehamburger1993 avatar whitead avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

colvars's Issues

How to handle per-atom masses?

In LAMMPS it is possible to set per-atom masses, not only per-atomtype. The issue of mapping atom types to atom ids requires significant temporary storage and communication during initialization. Wouldn't it be easier and more general if the colvars module would assume per-atom masses instead and the proxy module would provide that information, once it knows for which atom indices this information is required?

Adding interface to return uniform pRNG to colvarproxy

The code at:
https://github.com/colvars/colvars/blob/master/src/colvarbias_alb.cpp#L209

      //stochastic if we do that update or not
      if (colvars.size() == 1 || rand() < RAND_MAX / ((int) colvars.size())) {
        coupling_accum[i] += step_size * step_size;
        current_coupling[i] = set_coupling[i];
        set_coupling[i] += max_coupling_range[i] / sqrt(coupling_accum[i]) * step_size;
        coupling_rate[i] = (set_coupling[i] - current_coupling[i]) / update_freq;
        //set to the minimum rate and then put the sign back on it
        coupling_rate[i] = copysign(fmin(fabs(coupling_rate[i]), max_coupling_rate[i]), coupling_rate[i]);
      } else {
        coupling_rate[i] = 0;
      }

uses the pRNG from the system library (which may be of questionable quality). Wouldn't it be cleaner to add an interface to a uniform pRNG to the colvarproxy class? same as for gaussian distributed? return value would be a cvm::real between 0.0 and 1.0.

Variable-length arrays alternative?

These are clearly not portable across different C++ platforms, however they could be useful to decrease overhead associated with allocation and deallocation of short-lived vectors and matrices.

At the moment, the affected types are vector1d and matrix2d, which are often used as local-scope variables (stack), but their internal data are dyamically allocated by the "new" operator (heap).

Support restarting in LAMMPS

In addition to writing it own restart file, the status of the colvars should be embedded to and restored from LAMMPS binary restart files. For that purpose, serialization to a string and deserialization from a string (via stringstreams) should be added to the lammps proxy.

License

Hi! Thanks for posting colvars on github! I've forked colvars and am using it for my own research (I'm a postdoc in Greg Voths group). I noticed there is no license anywhere though in the code. I presume its meant to be open-source, since it's public on github, but I'd just like to double check with the developers and request the license be made explicit. Thank you!

Stop subtracting applied forces from total forces

It is becoming increasingly difficult (e.g. in message-passing parallelism) to perform an easy bookkeeping of the forces applied to each atom via different code paths (individual atoms vs. scalable groups).
The most practical solution is to stop reporting "system forces" acting on individual collective variables, and report instead for each variable the total force alongside the applied force. This will create the following changes in behavior:

  1. The boolean flag outputSystemForce of a colvar should be deprecated and replaced by outputTotalForce. When a colvar's configuration has outputSystemForce set to on (it is off by default), the code should trigger an error condition and prompt the user to to change the configuration to outputTotalForce. No changes are needed to outputAppliedForce.
  2. The ABF object must still subtract its own biasing force from the total force to perform TI-based free energy calculations (this is actually the original requirement for system forces in the first place). Therefore, it will carry out this subtraction internally (currently, this is done at the level of the entire code). To keep track of the time evolution of the system force, outputSystemForce can be enabled in the context of ABF only.
  3. Potentials of mean force calculated by ABF or by other TI-based integration of the system forces will be fully consistent with the output of umbrella sampling and metadynamics.

enumeration warnings

can these be safely ignored?

axel.

colvarbias_meta.cpp: In member function ‘virtual void colvarbias_meta::calc_hil
ls_force(const size_t&, colvarbias_meta::hill_iter, colvarbias_meta::hill_iter,
std::vector&, const std::vector&)’:
colvarbias_meta.cpp:700:10: warning: enumeration value ‘type_unitvectorderiv’ n
ot handled in switch [-Wswitch]
switch (colvars[i]->type()) {
^
colvarbias_meta.cpp:700:10: warning: enumeration value ‘type_quaternionderiv’ n
ot handled in switch [-Wswitch]
colvarbias_meta.cpp:700:10: warning: enumeration value ‘type_all’ not handled i
n switch [-Wswitch]
colvarvalue.cpp: In function ‘std::ostream& operator<<(std::ostream&, const colvarvalue&)’:
colvarvalue.cpp:210:10: warning: enumeration value ‘type_all’ not handled in switch [-Wswitch]
switch (x.type()) {
^

Minor initialization glitch

When the module is initialized empty in NAMD, and the first "cv config" command is issued after a "run 0", atomic coordinates are not updated during subsequent runs. The error is detected by all variables having zero value.

size_t vs. signed variables

Please check out commit a8a4ad9
This not only silences warning about using uninitialized variables, but also changes return values from -1 to 0 for several of the affected APIs. size_t is unsigned and thus returning -1 may lead to unexpected results. It is not obvious to me, how these are supposed to be used, so it may be worth to consider the alternate solution of changing the prototype to return an int (or a long int?) and then reinstate the -1.

steinhardt bond order parameter

Hello list:
Could I request the addition of the Steinhardt bond order parameters (Q,W) as a colvars component? These are implemented in the CP2K code, but I was unable to find an implementation here. Of course, if there is already something like this implemented please forgive my not reading of the manual.

Best
--Mike

New implementation (dipoleAngle component)

Hello, first of all thank you for this great module, Colvars, it has been very useful for our lab. I write to you because I'm implementing a "new" collectible variable (on Colvar source code), "dipoleAngle". This new collective variable is very similar to "angle", but measure/orients the dipole angle of a molecule. This implementation works for harmonic bias and metadynamics, but (still) not for ABF with "hideJacobian true" option , because I don't know how to calculate the "inverse gradient" and the "Jacobian derivative" of my new colvar. I've read the Colvar paper, some cites of this paper and the tutorial-abf.pdf but I still don't figure out how to calcute it.

If you can help me with this I'll be very greatful and I'll be able to make a pull request.

I leave you a link to the new collective variable development http://dlab.cl/wp-content/uploads/2015/03/development_colvar.pdf

Thanks

to minimum image or not to minimum image

After the issue with teaching fix colvars to use unwrapped instead of the "normal" (for LAMMPS) wrapped coordinates, there is now the question, how to overall handle the situation for when to compute the minimum image distance of two atoms (e.g. for bond, angles, dihedrals etc.) or not. this issue came up a while ago within LAMMPS with the following outcome: in most of the cases, it doesn't make a difference, however, in some corner cases, it does and there it would be better to not compute the minimum image.
the cases that then showed inconsistent before/after results all had bad input data (i.e. wrapped starting coordinates with bonds stretching across the box).

so the question is, what policy/convention should be adopted by colvars? it is somewhat arbitrary and it think it is most important to be consistent. with that in mind i plan to completely drop the option to use wrapped coordinates in fix colvars and present users with a single consistent view on how colvars are applied. even it it is no effort to leave the option in, it just confuses the wrong people and there is not much to gain from it.

Well-tempered metadynamics not working without grids

So I ran into another non-grids related issue,* with well-tempered metadynamics only being able to get the current hill energy through a grid. When no grids are defined, the code will just end with a segfault.

Here's a patch that adds support for the no grids case:
https://gist.github.com/kbal/2401ad97b9670329bf69
I didn't test it very thoroughly, but it seems to be okay. Anyway, please verify I didn't introduce additional bugs or something in that fashion.

*am I really such an outcast for not using them? :-)

XYZ file parser

To be implemented as colvarmodule member (accessible to all codes simultaneously).

problem with restarting colvars traj

I have run LAMMPS with 1 jul,13, version. with updated files from LAMMPS-ICMS which are bug free.. but while restarting the jobs, its giving "Segmentation fault (core dumped) "

I am unable to restart the jobs..

Thanks
Karteek Kumar

colvars restart files

Hello,

I have tried running a reaxc simulation with a colvars fix in lammps (version 21 Feb 2013). For some reason I am not getting restart and free energy output files (except for the last iteration free energy output and state files) despite using the setting colvarsRestartFrequency = 1 in colvars configuration file.
Thanks,

Osvalds

Common regtests for all backends

New directory structure:
colvars/tests/<nnn>_<title>/<name>.in

By default, this is enough to run a test with default VMD/NAMD/LAMMPS input, eg:
namd/tests/library/Common/test.namd

Test dirs may contain an extra input file, eg:
namd/tests/library/<nnn>_<title>/<name>.namdwhich may source the common input.

Backend-specific inputs (ie scripted) go to <backend>/tests/interface.

Mismatch of colvars outputs when "wrapAll" is turned on

As I used to turn "wrapAll on" in the namd configuration file and I expected it does no effect on the calculation. However when it combines with colvars, which affects the calculation, I am confused what will colvars read in after continuing from a previous dcd (wrapped).

In fact, I have done continuing simulation, namely run-1 then run-2, twice with "wrapAll on" and with "wrapAll off". It turns out the one with "wrapAll off" will give reasonable outputs in which the last line of colvars.traj of run-1 is as same as the first line of colvars.traj of run-2. On the other hand, the one with "wrapAll on" does not behave like this.

I will attach my colvar.in and configuration file but they are just conventional things. Still, hope they will help.

colvars.in:

colvarsTrajFrequency     1000
colvarsRestartFrequency  1000

colvar {
   name dih

   width 1.0
   outputValue on

   dihedral {
       group1 {
         atomsFile group2.pdb
         atomsCol B
         atomsColValue 1.0
       }
       group2 {
         atomsFile group1.pdb
         atomsCol B
         atomsColValue 1.0
       }
       group3 {
         atomsFile group3.pdb
         atomsCol B
         atomsColValue 1.0
       }
       group4 {
         atomsFile group4.pdb
         atomsCol B
         atomsColValue 1.0
       }
       oneSiteSystemForce yes
   }

   outputSystemForce yes
   outputAppliedForce yes
}

harmonic {
  name diah_pot
  colvars dih
  centers -11.0
  forceConstant 10.0
}

run.namd:

firsttimestep 0

structure       ../ionized.psf
coordinates     ../ionized.pdb

Bincoordinates  ./output/NPT-0.restart.coor
Binvelocities   ./output/NPT-0.restart.vel
ExtendedSystem  ./output/NPT-0.restart.xsc

outputname       ./output/NPT-1

COMmotion yes

paraTypeCharmm      on
parameters          ../par_CMAP.inp

exclude             scaled1-4
1-4scaling          1.0
cutoff              12.0
switching           on
switchdist          10.0
pairlistdist        13.5

timestep            2.0
rigidBonds          all
nonbondedFreq       1
fullElectFrequency  2
stepspercycle       20

langevin            on
langevinDamping     5.0
langevinTemp        310.0
langevinHydrogen    off

wrapAll             on

PME                 yes
PMEGridSpacing 1.0

langevinPiston        on
langevinPistonTarget  1.01325
langevinPistonPeriod  2000.0
langevinPistonDecay   2000.0
langevinPistonTemp    310.0

restartfreq         1000
dcdfreq             1000
xstFreq             1000
outputEnergies      100
outputPressure      100

colvars             on

Two step initialization in proxy class for LAMMPS

To make initialization more flexible, break it into two steps: the constructor and an init() function. The latter will create an instance of the colvarmodule class, which needs a completely instantiated proxy class for reporting error messages. The init() function may be called from different places and multiple during the lifetime of fix colvars in LAMMPS, so the one time initialization has to be properly protected from being executed more than once.

colvars library requires tcl.h header

i am not happy with the change that makes the colvars library itself depend on Tcl development.
isn't there a way to move the Tcl specific part of the code to the NAMD/VMD specific directories?

In file included from colvar.cpp:8:0:
colvarscript.h:7:17: fatal error: tcl.h: No such file or directory
#include <tcl.h>
^
compilation terminated.
make[1]: *** [colvar.o] Error 1
make[1]: Leaving directory `/home/akohlmey/compile/lammps-icms/lib/colvars'

Doubt about constant in angle::calc_gradients

Hello,
I was checking the colvar::angle::calc_gradients() function and I have a doubt about a constant that I can't figure out why is there. In the next lines,

dxdr1 = (180.0/PI) * dxdcos *
    (1.0/r21l) * ( r23/r23l + (-1.0) * cos_theta * r21/r21l );

dxdr3 = (180.0/PI) * dxdcos *
    (1.0/r23l) * ( r21/r21l + (-1.0) * cos_theta * r23/r23l );

there is a constant (180.0/PI) that doesn't appears in the gradient of angle. I know that constant is used to transform from radians to degree (like in line 68 in that same file), but in this case that's not necessary, because we need the expression in radians to calculate the force. Maybe there is another part of the code that needs that constant?.

I'm checking this because I need to know about that constant for the dipole_angle implementation that I developed in the proxy branch.

Cheers!

combine ABF strata in LAMMPS

I have a question regarding the stratification in ABF using colvars. Based on what I read in papers, I'm thinking of divide my simulation transition coordinate into N non-overlapping windows to enhance the performance of the sampling. After doing independent simulations in each stratum (windows) I need to combine the result to recover the full PMF along the transition coordinate, the "COLLECTIVE VARIABLES MODULE
Reference manual for LAMMPS" says:

"If the colvar space has been partitioned into sections (windows) in which independent ABF simulations have been run, the resulting data can be merged using the the input keyword of the fix ID group-ID colvars command."

So I was wondering if it means that I should pass 'output01.pmf', 'output01.pmf', ...,'outputN.pmf' files to get a combined PMF results?!

Because what I understand from 'fix colvars' manual is that the input option is to specify a state file in order to continue the simulation. So I don't know how it can be used to combine the results.

I would really appreciate it if you can clarify that for me.

Cheers,
Kasra.

Conflicts in doc when merging branches

The issue is much milder than a few months ago (when we had separate html files), however htlatex often generates extensive changes to the HTML documentation corresponding to tiny changes in the actual source. Aside from inflating the size of commits (which is harmless), merging is a bit more difficult.

Solution A: we move doc and examples to a separate sub-repository.
Solution B: we just don't document stuff until it gets into the master branch.

append option for group2ndx

For those who need to re-use more than 32 LAMMPS groups as groups for collective variables, an option "append" can allow to write more than 32 groups all to the same index file.
(When not using group2ndx, multiple index files may be joined together just using "cat".)

Add optional cap on biasing force

In cases where the PMF has a singularity, the discretized adaptive force becomes inaccurate, possibly resulting in trapped dynamics, as happens in this NAMD user's case.

One solution (somewhat ad-hoc) is to cap the biasing force applied. This could be done either at the bias level, or at the colvar level (on the total bias force).

  • Argument in favor of ABF doing this: more fine-grained control, especially when several biases work simultaneously and the forces overlap.
  • Argument in favor of the colvar: more general, can be used by other biases - eg. harmonic biases for CHARMM-style NOE restraints.
  • third option : add this at the generic bias level, still flexible but keeping finer control.

This issue is open for comments!

output prefix problem

I am using colvars version 2014-10-13.
I have lammps-28Jun14 patched up to 9Oct14.
There seems to be something wrong with the output prefix. Regardless of whether I specify it or leave it as default ("out"), it ends up being undefined. The colvars.state file gets named just colvars.state, and any histogram and pmf files get named .histogram1.dat or .pmf, etc. In the past, I have used colvars version 2013-6-19 without this issue.
Does anybody have an idea what could be going on here?

Regression tests for LAMMPS

A number of regression tests that test and document the behavior of the LAMMPS interface and the colvars code in general need to be added.

Valgrind Issues in colvars destructors

I was just informed by the LAMMPS regtest team that colvars throws some valgrind errors with the minimal provided examples. one of the issues is on the LAMMPS side and fixed in commit 7cd6546
however there is more and this seems to come from way within the colvars library. see an example valgrind output below (please note that the line numbers are off, since i have a chunk of debug statements in my copy of the code), and have yet to find a way to make sense of it. this seems to be generic.

any ideas?

axel.

==21380== Invalid read of size 8
==21380==    at 0x132DB72: __gnu_cxx::__normal_iterator<colvarbias**, std::vector<colvarbias*, std::allocator<colvarbias*> > >::__normal_iterator(colvarbias** const&) (stl_iterator.h:729)
==21380==    by 0x132C3E6: std::vector<colvarbias*, std::allocator<colvarbias*> >::begin() (stl_vector.h:548)
==21380==    by 0x1371241: colvarbias::~colvarbias() (colvarbias.cpp:68)
==21380==    by 0x135C51A: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:148)
==21380==    by 0x135C5E5: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:177)
==21380==    by 0x1326442: colvarmodule::reset() (colvarmodule.cpp:678)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==  Address 0x11170d40 is 112 bytes inside a block of size 4,056 free'd
==21380==    at 0x4A08103: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21380==    by 0x13263B3: colvarmodule::reset() (colvarmodule.cpp:670)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==    by 0x7E0838: LAMMPS_NS::Modify::~Modify() (modify.cpp:144)
==21380==    by 0x8D016C: LAMMPS_NS::LAMMPS::destroy() (lammps.cpp:729)
==21380==    by 0x8D01D8: LAMMPS_NS::LAMMPS::~LAMMPS() (lammps.cpp:550)
==21380==    by 0x60738D: main (main.cpp:32)
==21380== 
==21380== Invalid read of size 8
==21380==    at 0x132DB72: __gnu_cxx::__normal_iterator<colvarbias**, std::vector<colvarbias*, std::allocator<colvarbias*> > >::__normal_iterator(colvarbias** const&) (stl_iterator.h:729)
==21380==    by 0x132C410: std::vector<colvarbias*, std::allocator<colvarbias*> >::end() (stl_vector.h:566)
==21380==    by 0x1371309: colvarbias::~colvarbias() (colvarbias.cpp:69)
==21380==    by 0x135C51A: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:148)
==21380==    by 0x135C5E5: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:177)
==21380==    by 0x1326442: colvarmodule::reset() (colvarmodule.cpp:678)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==  Address 0x11170d48 is 120 bytes inside a block of size 4,056 free'd
==21380==    at 0x4A08103: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21380==    by 0x13263B3: colvarmodule::reset() (colvarmodule.cpp:670)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==    by 0x7E0838: LAMMPS_NS::Modify::~Modify() (modify.cpp:144)
==21380==    by 0x8D016C: LAMMPS_NS::LAMMPS::destroy() (lammps.cpp:729)
==21380==    by 0x8D01D8: LAMMPS_NS::LAMMPS::~LAMMPS() (lammps.cpp:550)
==21380==    by 0x60738D: main (main.cpp:32)
==21380== 
==21380== Invalid read of size 8
==21380==    at 0x13712B1: colvarbias::~colvarbias() (colvarbias.cpp:72)
==21380==    by 0x135C51A: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:148)
==21380==    by 0x135C5E5: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:177)
==21380==    by 0x1326442: colvarmodule::reset() (colvarmodule.cpp:678)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==    by 0x7E0838: LAMMPS_NS::Modify::~Modify() (modify.cpp:144)
==21380==    by 0x8D016C: LAMMPS_NS::LAMMPS::destroy() (lammps.cpp:729)
==21380==  Address 0xdfe77b0 is 0 bytes inside a block of size 8 free'd
==21380==    at 0x4A08103: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21380==    by 0x1330F47: __gnu_cxx::new_allocator<colvarbias*>::deallocate(colvarbias**, unsigned long) (new_allocator.h:110)
==21380==    by 0x133067A: __gnu_cxx::__alloc_traits<std::allocator<colvarbias*> >::deallocate(std::allocator<colvarbias*>&, colvarbias**, unsigned long) (alloc_traits.h:185)
==21380==    by 0x132F5F5: std::_Vector_base<colvarbias*, std::allocator<colvarbias*> >::_M_deallocate(colvarbias**, unsigned long) (stl_vector.h:178)
==21380==    by 0x132E073: std::_Vector_base<colvarbias*, std::allocator<colvarbias*> >::~_Vector_base() (stl_vector.h:160)
==21380==    by 0x133170B: std::vector<colvarbias*, std::allocator<colvarbias*> >::~vector() (stl_vector.h:425)
==21380==    by 0x13AD544: colvar::~colvar() (colvar.cpp:816)
==21380==    by 0x13263AB: colvarmodule::reset() (colvarmodule.cpp:670)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380== 
==21380== Invalid read of size 8
==21380==    at 0x132DB72: __gnu_cxx::__normal_iterator<colvarbias**, std::vector<colvarbias*, std::allocator<colvarbias*> > >::__normal_iterator(colvarbias** const&) (stl_iterator.h:729)
==21380==    by 0x132C410: std::vector<colvarbias*, std::allocator<colvarbias*> >::end() (stl_vector.h:566)
==21380==    by 0x137211A: std::vector<colvarbias*, std::allocator<colvarbias*> >::_M_erase(__gnu_cxx::__normal_iterator<colvarbias**, std::vector<colvarbias*, std::allocator<colvarbias*> > >) (vector.tcc:144)
==21380==    by 0x13720BA: std::vector<colvarbias*, std::allocator<colvarbias*> >::erase(__gnu_cxx::__normal_iterator<colvarbias**, std::vector<colvarbias*, std::allocator<colvarbias*> > >) (stl_vector.h:1150)
==21380==    by 0x13712E0: colvarbias::~colvarbias() (colvarbias.cpp:73)
==21380==    by 0x135C51A: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:148)
==21380==    by 0x135C5E5: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:177)
==21380==    by 0x1326442: colvarmodule::reset() (colvarmodule.cpp:678)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==  Address 0x11170d48 is 120 bytes inside a block of size 4,056 free'd
==21380==    at 0x4A08103: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21380==    by 0x13263B3: colvarmodule::reset() (colvarmodule.cpp:670)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==    by 0x7E0838: LAMMPS_NS::Modify::~Modify() (modify.cpp:144)
==21380==    by 0x8D016C: LAMMPS_NS::LAMMPS::destroy() (lammps.cpp:729)
==21380==    by 0x8D01D8: LAMMPS_NS::LAMMPS::~LAMMPS() (lammps.cpp:550)
==21380==    by 0x60738D: main (main.cpp:32)
==21380== 
==21380== Invalid read of size 8
==21380==    at 0x1372184: std::vector<colvarbias*, std::allocator<colvarbias*> >::_M_erase(__gnu_cxx::__normal_iterator<colvarbias**, std::vector<colvarbias*, std::allocator<colvarbias*> > >) (vector.tcc:146)
==21380==    by 0x13720BA: std::vector<colvarbias*, std::allocator<colvarbias*> >::erase(__gnu_cxx::__normal_iterator<colvarbias**, std::vector<colvarbias*, std::allocator<colvarbias*> > >) (stl_vector.h:1150)
==21380==    by 0x13712E0: colvarbias::~colvarbias() (colvarbias.cpp:73)
==21380==    by 0x135C51A: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:148)
==21380==    by 0x135C5E5: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:177)
==21380==    by 0x1326442: colvarmodule::reset() (colvarmodule.cpp:678)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==  Address 0x11170d48 is 120 bytes inside a block of size 4,056 free'd
==21380==    at 0x4A08103: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21380==    by 0x13263B3: colvarmodule::reset() (colvarmodule.cpp:670)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==    by 0x7E0838: LAMMPS_NS::Modify::~Modify() (modify.cpp:144)
==21380==    by 0x8D016C: LAMMPS_NS::LAMMPS::destroy() (lammps.cpp:729)
==21380==    by 0x8D01D8: LAMMPS_NS::LAMMPS::~LAMMPS() (lammps.cpp:550)
==21380==    by 0x60738D: main (main.cpp:32)
==21380== 
==21380== Invalid write of size 8
==21380==    at 0x1372190: std::vector<colvarbias*, std::allocator<colvarbias*> >::_M_erase(__gnu_cxx::__normal_iterator<colvarbias**, std::vector<colvarbias*, std::allocator<colvarbias*> > >) (vector.tcc:146)
==21380==    by 0x13720BA: std::vector<colvarbias*, std::allocator<colvarbias*> >::erase(__gnu_cxx::__normal_iterator<colvarbias**, std::vector<colvarbias*, std::allocator<colvarbias*> > >) (stl_vector.h:1150)
==21380==    by 0x13712E0: colvarbias::~colvarbias() (colvarbias.cpp:73)
==21380==    by 0x135C51A: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:148)
==21380==    by 0x135C5E5: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:177)
==21380==    by 0x1326442: colvarmodule::reset() (colvarmodule.cpp:678)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==  Address 0x11170d48 is 120 bytes inside a block of size 4,056 free'd
==21380==    at 0x4A08103: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21380==    by 0x13263B3: colvarmodule::reset() (colvarmodule.cpp:670)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==    by 0x7E0838: LAMMPS_NS::Modify::~Modify() (modify.cpp:144)
==21380==    by 0x8D016C: LAMMPS_NS::LAMMPS::destroy() (lammps.cpp:729)
==21380==    by 0x8D01D8: LAMMPS_NS::LAMMPS::~LAMMPS() (lammps.cpp:550)
==21380==    by 0x60738D: main (main.cpp:32)
==21380== 
==21380== Invalid read of size 8
==21380==    at 0x1372198: std::vector<colvarbias*, std::allocator<colvarbias*> >::_M_erase(__gnu_cxx::__normal_iterator<colvarbias**, std::vector<colvarbias*, std::allocator<colvarbias*> > >) (vector.tcc:147)
==21380==    by 0x13720BA: std::vector<colvarbias*, std::allocator<colvarbias*> >::erase(__gnu_cxx::__normal_iterator<colvarbias**, std::vector<colvarbias*, std::allocator<colvarbias*> > >) (stl_vector.h:1150)
==21380==    by 0x13712E0: colvarbias::~colvarbias() (colvarbias.cpp:73)
==21380==    by 0x135C51A: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:148)
==21380==    by 0x135C5E5: colvarbias_abf::~colvarbias_abf() (colvarbias_abf.cpp:177)
==21380==    by 0x1326442: colvarmodule::reset() (colvarmodule.cpp:678)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==  Address 0x11170d48 is 120 bytes inside a block of size 4,056 free'd
==21380==    at 0x4A08103: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21380==    by 0x13263B3: colvarmodule::reset() (colvarmodule.cpp:670)
==21380==    by 0x98C329: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:157)
==21380==    by 0x98C618: colvarproxy_lammps::~colvarproxy_lammps() (colvarproxy_lammps.cpp:161)
==21380==    by 0xA94638: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:351)
==21380==    by 0xA94708: LAMMPS_NS::FixColvars::~FixColvars() (fix_colvars.cpp:361)
==21380==    by 0x7DD839: LAMMPS_NS::Modify::delete_fix(char const*) (modify.cpp:864)
==21380==    by 0x7E05F0: LAMMPS_NS::Modify::~Modify() (modify.cpp:108)
==21380==    by 0x7E0838: LAMMPS_NS::Modify::~Modify() (modify.cpp:144)
==21380==    by 0x8D016C: LAMMPS_NS::LAMMPS::destroy() (lammps.cpp:729)
==21380==    by 0x8D01D8: LAMMPS_NS::LAMMPS::~LAMMPS() (lammps.cpp:550)
==21380==    by 0x60738D: main (main.cpp:32)
==21380== 

Compile on Blue Gene Q using mpixlcxx_r

Dear Developers,

I am using a Makefile on a Blue Gene Q machine with the following settings for CXX and CXXFLAGS:
CXX = /bgsys/drivers/ppcfloor/comm/xl.ndebug/bin/mpixlcxx_r
CXXFLAGS = -g -O3 -qarch=qp -qtune=qp -qsmp=omp -qstrict

Such a makefile works well for the colvars library distributed with LAMMPS version dated 30Oct14. However, the compiler issues an error if I use these settings with the corresponding libraries distributed with LAMMPS versions dated 9Dec14 (latest stable) and 16Feb15 (developers). The error is as follows:

"colvartypes.h", line 327.5: 1540-1113 (S) The class template name "matrix2d" must be followed by a < in this context."

All of the these libraries are compiled successfully by the GNU compiler on the same system. Could you please advise on possible resolutions for this error?

I appreciate your help!
Thanks,
Ketan

Turn walls into a separate bias

Caveat: extended-Lagrangian colvars, where we want the walls to be applied to the actual coordinate.

More generally, we'll probably need a mechanism for applying biases either to the extended DOF, or to the geometric coordinate "actual value".

Linking error

When I like COLVARS with LAMMPS I get the following undefined symbols:

colvarbias_alb::colvarbias_alb(std::string const&, char const_)'
colvarbias_restraint_harmonic::colvarbias_restraint_harmonic(std::string const&, char const_)'
colvarbias_restraint_linear::colvarbias_restraint_linear(std::string const&, char const*)'
colvarmodule::quaternion::from_simple_string(std
colvarmodule::quaternion::position_derivative_inner(colvarmodule
colvarmodule::quaternion::to_simple_string() const'
colvarmodule::rotation::calc_optimal_rotation(std
colvarmodule::rotation::crossing_threshold'
colvarmodule::rotation::monitor_crossings'
colvarmodule::rvector::from_simple_string(std
colvarmodule::rvector::to_simple_string() const'
operator>>(std::istream&, colvarmodule::quaternion&)'
operator>>(std::istream&, colvarmodule::rvector&)'
operator<<(std::ostream&, colvarmodule::quaternion const&)'
operator<<(std::ostream&, colvarmodule::rvector const&)'

e.g.

mpicxx -O3 -L../../lib/colvars ...... -lcolvars ....

Undefined symbols for architecture x86_64:
"colvarmodule::quaternion::from_simple_string(std::basic_string<char,
std::char_traits, std::allocator > const&)", referenced from:
colvarvalue::from_simple_string(std::basic_string<char,
std::char_traits, std::allocator > const&) in
libcolvars.a(colvarvalue.o)

Segfault when using metadynamics without grids

I found that when using COLVARS in LAMMPS to perform metadynamics without grids (so useGrids = off), LAMMPS will segfault when deleting the colvar fix or when finishing itself. This is due to the destructor of the colvarbias_meta class: although it checks whether the pointers hills_energy and hills_energy_gradients actually point to freeable memory, this check seems to fail on my system.

Explicitly setting both of them to be NULL in the constructor in the case of use_grids == false solves the issue for me.

Best wishes,
Kristof Bal
University of Antwerp

Uniform treatment of forces on "single-particle" vs. normal atom groups

To properly handle fit gradients for all CVCs in an efficient way, we need to know whether atom groups are involved as their COG/COM, or if the cvc depends on individual coordinates in a more complicated way.

A more general approach is to store a vector of weights, providing for all linear combinations of coordinates (or a weight matrix for vector cvcs).

In those cases, we need to store per-group gradients, instead of per-atom.

Regression test for ALB

Since the main developers are not familiar with ALB, we risk breaking it in a future update if we don't have a unit test.

Implement atomic gradients for non-scalar CVCs

Currently they are either calculated on the fly (distanceDir, distanceVec) or stored in a different data structure (orientation -> cvm::rotation object). There can be two solutions to this:

  • add additional 3-vectors in each cvm::atom object (problem: increases memory usage for all variables);
  • store additional vectors of 3-vectors as needed in cvm::atom_group (problems: breaks data contiguity).

What should be the behavior of colvars during minimization?

Parts of the functionality of the colvars library (e.g. restraints, analysis of collective variables) makes would make sense to be used during minimization, others less so. What should be the behavior of the module? should we have a flag that is passed to cvm::calc() to indicate what run type we have?

Adding atoms on the fly in NAMD requires one timestep delay

When a config loaded after NAMD startup requires new atoms, the data only becomes available one timestep later. Trying to access it on the same timestep triggers a this error:
FATAL ERROR: GlobalMasterServer::callClients() did not find all requested atoms

The solution to that is to implement a one-timestep delay before coordinates are accessed and the colvar can be computed - and biases that use it, as well.

A workaround until then is to request those atoms preemptively at an earlier stage.

Mutable shared variables

The added support for shared-memory parallelism introduces a problem with shared variables. These are mostly in the cvm class and are usually read-only so far as multiple threads are concerned. Two notable exceptions are cvm::errorCode and cvm::depth. Currently, neither flag poses a serious risk of data corruption: in NAMD, most errors occur at init time, and all errors result in near-immediate termination of the process. For cvm::depth, I am removing calls to cvm::increase_depth() and cvm::decrease_depth() from functions that are called simultaneously.

A possible solution is allowing the new dependency tree class (or a similarly-designed base class) handle contain a local errorCode field. Error codes of multiple children objects could be bitwise-OR'ed by the parent object.

VMD seg fault on syntax error in cv definition

This bug refers to the implementation of Colvars in VMD. When configuring the colvar, any error in syntax causes a seg fault that terminates VMD. As a simple example, the following code results in a seg fault when entered into tkcon console (VMD console dump is given below):

mol new 1GWR
set sel1 [atomselect top "noh chain A and resid 533 to 536"]
set sel2 [atomselect top "noh chain A and resid 339 to 351"]
cv molid top
cv config \
"colvar {
    name cn
    coordNum {
        group1 { atomNumbers [$sel1 get serial] }
        group2 { atomNumbers [$sel2 get serial] }
    }}"

The error is that the closing braces are on the same line, i.e., the following code is the corrected version:

mol new 1GWR
set sel1 [atomselect top "noh chain A and resid 533 to 536"]
set sel2 [atomselect top "noh chain A and resid 339 to 351"]
cv molid top
cv config \
"colvar {
    name cn
    coordNum {
        group1 { atomNumbers [$sel1 get serial] }
        group2 { atomNumbers [$sel2 get serial] }
    }
}"

In my experience, this occurs with any syntactical error provided either directly within VMD, as shown above, or by providing a config file. Here is the console data from VMD demonstrating the seg fault, including the Version of VMD (I can reproduce this on Mac OS X version of VMD as well):

Info) VMD for LINUXAMD64, version 1.9.2 (December 29, 2014)
Info) http://www.ks.uiuc.edu/Research/vmd/
Info) Email questions and bug reports to [email protected]
Info) Please include this reference in published work using VMD:
Info) Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual
Info) Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
Info) -------------------------------------------------------------
Info) Multithreading available, 8 CPUs detected.
Info) Free system memory: 23441MB (97%)
Info) Creating CUDA device pool and initializing hardware...
Info) Detected 1 available CUDA accelerator:
Info) [0] GeForce GTX 570 15 SM_2.0 @ 1.46 GHz, 1.2GB RAM, KTO, AE1, ZCP
Info) Detected 1 available TachyonL/OptiX ray tracing accelerator
Warning) Detected X11 'Composite' extension: if incorrect display occurs
Warning) try disabling this X server option. Most OpenGL drivers
Warning) disable stereoscopic display when 'Composite' is enabled.
Info) OpenGL renderer: GeForce GTX 570/PCIe/SSE2
Info) Features: STENCIL MSAA(4) MDE CVA MTX NPOT PP PS GLSL(OVFGS)
Info) Full GLSL rendering mode is available.
Info) Textures: 2-D (16384x16384), 3-D (2048x2048x2048), Multitexture (4)
Info) Dynamically loaded 2 plugins in directory:
Info) /Projects/vmd/pub/linux64/lib/vmd192/plugins/LINUXAMD64/molfile
after#0
vmd > source setupCV_broken.tcl
The PDB is supported by RCSB, the NSF, US PHS, NIH, NCRP, NIGMS, NLM,
and US DoE, who are not liable for the data. PDB files shall not be
sold. See ftp://ftp.rcsb.org/advisory.doc for full details.
Info) Using plugin webpdb for structure file 1GWR
Info) Using plugin webpdb for coordinates from file 1GWR
Info) Determining bond structure from distance search ...
Info) Analyzing structure ...
Info) Atoms: 3987
Info) Bonds: 4016
Info) Angles: 0 Dihedrals: 0 Impropers: 0 Cross-terms: 0
Info) Bondtypes: 0 Angletypes: 0 Dihedraltypes: 0 Impropertypes: 0
Info) Residues: 542
Info) Waters: 45
Info) Segments: 1
Info) Fragments: 55 Protein: 8 Nucleic: 0
colvars: ----------------------------------------------------------------------
colvars: Initializing the collective variables module, version 2014-10-13.
colvars: ----------------------------------------------------------------------
colvars: Reading new configuration:
colvars: # indexFile = "" [default]
colvars: # analysis = off [default]
colvars: # colvarsTrajFrequency = 0 [default]
colvars: # colvarsRestartFrequency = 0 [default]
colvars: # colvarsTrajAppend = off [default]
colvars: ----------------------------------------------------------------------
colvars: Initializing a new collective variable.
colvars: # name = "colvar1" [default]
colvars: Error: no valid components were provided for this collective variable.
colvars: All components initialized.
Segmentation fault (core dumped)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.