search

plumed / plumed2

Development version of plumed 2
https://www.plumed.org
GNU Lesser General Public License v3.0
357 stars 284 forks source link

Charges and masses in driver #112

Closed GiovanniBussi closed 9 years ago

GiovanniBussi commented 10 years ago

It's a bit annoying that we can't use driver to compute quantities depending on electrostatic charge (e.g. DHENERGY). For masses the situation is even worst: in the driver they are set to 1. Thus, COM will give a slightly different result when used in MD or in driver. In principle this can be circumvented by passing a pdb to driver (as done in Toni's plugin), but this is not completely satisfactory to me because creating that pdb is complicated and because of the limited number of digits available. What I do in practice now is I use "gromacs rerun" stuff whenever I have to compute mass-based or charge-based quantities.

I am planning a workaround such as:

The second stuff could be done from the command line of "plumed driver" as well, but I think that a replacement command within the plumed.dat file could be more flexible.

Any further idea is welcome!

Giovanni

tonigi commented 10 years ago

One could read a PSF file perhaps - either partially parsing it or via the molfile plugin. Not especially helpful for gromacs I'm afraid.

GiovanniBussi commented 10 years ago

@tonigi I think PSF is a very good idea. I will have a look to see how standard is the format and if it is easy to write a small parser to avoid being dependent on external libraries (at least for charges and masses). Note that it is not necessary to convert from gromacs top to PSF, but to write a PSF from a running simulation within PLUMED. This would make the thing more general (all MD codes that already pass masses and charges to PLUMED could be used to produce such a PSF file).

tonigi commented 10 years ago

@GiovanniBussi Parsing a PSF should be easy in a first approximation (read the lines after !NATOM, columns are space separated). Also there should be utilities to create a rough PSF from .top. But I'm afraid that driver does not have enough information to write (eg: residue names, types and so on). So many fields would be dummy that perhaps it's better not to call it a PSF?