steinhardt bond order parameter

[mikemitch]

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

[jhenin]

Hello Mike,

Due to limited manpower, we have no plans to implement this at this point. There seem to be a number of existing implementations, but I didn't see any that could be re-used here, due to license restrictions. We are effectively limited to permissive licences.

If you are willing to give it a shot though, we would certainly help you with it.

Best, Jerome

[giacomofiorin]

Hello Mike, do you use primarily LAMMPS or NAMD?

[mikemitch]

Hi Jérôme/Giacomo: Thanks for the reply. I currently mostly use LAMMPS for my sims. I'd be willing to work on coding this as well (I'm generally useful with C++). I presume that the bulk of the work would involve calculating the Legendre polynomials and getting the forces, but that is all coded in other programs already (i.e. CP2K) Are there quick pointers as to where to start modifying the current code?

Thanks --Mike

[giacomofiorin]

Hi Mike, great! Since the code organization is very different, I would take CP2K as a reference for benchmarks/regression tests, but would focus on getting a new implementation altogether. To implement a new colvar component, you simply need to add a new class to the colvarcomp*.cpp files, and refer to that new class in colvar.cpp and colvar.h (one line for each).

I would consider as a starting example the coordnum class, in colvarcomp_coordnums.cpp.

You could work on it off the main branch, master. In parallel to that, I'm also adding parallelization improvements in the proxy branch, and these will require eventually some changes to the colvarcomp* classes, but it's safe to say that these won't be major, especially if you structure your code in a way that makes use of for-loops similar to those of coordnum.

[akohlmey]

FYI, as it happens, Aidan Thompson just implemented a compute in LAMMPS that computes this parameter. http://lammps.sandia.gov/doc/compute_orientorder_atom.html He had asked me for help him to remove the dependency on BOOST, which we managed. Not sure if that is a big help here, but perhaps it might be worth discussing what a compute class would need to provide to interface it to colvars, and we could then use that mechanism, e.g. for push parallel processing into the host code.

[giacomofiorin]

I took a look at the Compute and ComputeOrientOrderAtom classes, and nothing stands out as clearly incompatible so far. I would say that the biggest issue now (unless I overlooked it) is the lack of atomic gradients and of a function used to apply a force to a compute.

To use this for parallel processing, a compute class would need to provide public methods (or have int flags such as those in the current Compute class) to check whether the following capabilities are implemented: A) Atomic gradients: with these, one can apply forces to enhance sampling, and do free energy calculation with methods that are more or less based on histograms (umbrella sampling, metadynamics, FEP, ...). B) Atomic inverse gradients: if these are implemented, one has access to ABF and other methods for free energy calculations derived from thermodynamic integration. C) Coordinate transformations: if it's possible to carry out a least-squares rotational fit of the atomic coordinates, one can define more accurately several functions that are otherwise not rotationally invariant (e.g. inertia tensor, RMSD). (The fit is currently performed by a colvar object, but could be easily ported to a Compute class for compatibility with the LAMMPS workflow).

For the specific example of the Steinhardt Compute, there is some work to be done to implement (A), it's very hard to achieve (B), and there is no need to provide (C).

[jhenin]

Closed, pending activity on this.