From: Giacomo Fiorin (giacomo.fiorin_at_gmail.com)
Date: Thu Mar 25 2021 - 09:52:13 CDT
Hi Carlo, Josh is correct. A zero beta column is the most likely
explanation: if not, please let us know.
When implementing the NAMD backend of the mapTotal variable (based on
GridForces), I tried to keep the new functionality as consistent as
possible with the use cases that Josh mentioned (custom electric fields,
MDFF, etc). But that also means inheriting technicalities like this one.
FYI there is a tutorial available at
https://urldefense.com/v3/__https://colvars.github.io/multi-map/multi-map.html__;!!DZ3fjg!qB5CRc-AwU64OMfr1bYNOpTM7vcKDjLCEAs9qFj1Im6wgSeelgHIHzs_KyZ-pcN1cg$ . The NAMD manual
doesn't have it linked, because I wrote it after NAMD 2.14 was released.
It's geared toward variables with more than one map, but for a single map
the syntax is otherwise almost identical, as I'm sure you noticed.
You may also find the latest VMD alpha build to visualize/test the
variable. (Note however that VMD doesn't have GridForces, so the way map
variables are defined there is slightly different).
Giacomo
On Thu, Mar 25, 2021 at 10:35 AM Vermaas, Josh <vermaasj_at_msu.edu> wrote:
> Hi Carlo,
>
> What is in the beta column? You are using the occupancy column to
> determine if the atoms should be coupled to the potential or not. But the
> "weight" for each atom also matters. For traditional grid forces, when it
> was being used to apply an electric field, folks would copy the atomic
> charges to the beta column so that a carbon and hydrogen atom wouldn't feel
> the same attractive force. MDFF folks will use the mass of the element. The
> point being, is that your beta column can't be zero, otherwise it doesn't
> contribute to the gridforce value colvars is depending on. If you just want
> to count waters, I *think* the correct thing is to have the "noh and water"
> have a 1 in the beta column. You should then see non-zero values for the
> colvar.
>
> -Josh
>
> On 3/25/21 6:22 AM, Carlo Guardiani wrote:
>
> Dear NAMD experts,
> I am trying to run simulations with volumetric map-based
> variables. At the moment I am trying to bias the number
> of water molecules inside the pore of an ion channel
> following the instructions in the Reference manual for
> the Collective Variables Module. I built the pore occupancy
> map using VMD on a preliminary trajectory
>
> set sel [atomselect top "water and (z > -40) and (z < 25) and
> (sqrt(x*x+y*y) < 12)"]
>
> volmap occupancy $sel -allframes -combine max -o Occupancy.dx
>
> package require volutil
>
> volutil -o Occupancy_smooth.dx -pad -smooth 0.0001 Occupancy.dx
>
> The map, visualized with VMD, looks reasonable in that all
> the pore region appears to be filled.
>
> Following the manual, I also created a file where all water
> molecules are marked in the occupancy column. Is that correct ?
> Maybe I had to mark only the water molecule initially inside the
> pore ? The file was generated with the following tcl script
>
> mol load pdb TMD_4HKR_to_6BBF_frame_0.pdb
> set all [atomselect top "all"]
> $all set occupancy 0
> set wat [atomselect top "water and (name O)"]
> $wat set occupancy 1
> $all writepdb mark_water.pdb
>
> I added the following commands to the main NAMD input file
>
> mGridForce yes
> mGridForcePotFile Cavity Occupancy_smooth.dx
> mGridForceFile Cavity mark_water.pdb
> mGridForceCol Cavity O
> mGridForceChargeCol Cavity B
> mGridForceScale Cavity 0.0 0.0 0.0
>
> colvars on
> colvarsConfig ./ColvarConfig.conf
>
> Finally, I defined in file ColvarConfig.conf a collective
> variable that, I expected, should count the number of water
> molecules in the cavity.
>
> colvar {
> name nwaters
> mapTotal {
> mapName Cavity
> componentCoeff 1.0
> }
> }
>
>
>
> harmonic {
> colvars nwaters
> centers 277 # centered around initial number of water
> molecules
> forceConstant 50000
> }
>
> As you can see, I applied an harmonic bias to keep the number
> of water molecules in the cavity close to the initial value
> (277 molecules). Here comes the problem: according to the
> .traj file the value of collective variable nwaters is constantly
> equal to zero which is clearly wrong. The system was run for 5.0 ns
> with NAMD 2.14. During the simulation the number of water molecules
> inside the pore made oscillations of the order of 10% with respect
> to the initial value. However, I suspect that an unbiased equilibrium
> simulation would have done the same, so that this cannot be used as
> a diagnostic criterium that the simulation is doing what it was
> intended to do.
>
> Could you please tell me what to do ? This is the first time I run this
> kind of simulations so that some trivial mistake is highly possible.
>
> Many thanks for your help,
>
> Carlo Guardiani
>
>
>
>
>
>
>
> ________________________________________________________
> Le informazioni contenute in questo messaggio di posta elettronica sono
> strettamente riservate e indirizzate esclusivamente al destinatario. Si
> prega di non leggere, fare copia, inoltrare a terzi o conservare tale
> messaggio se non si รจ il legittimo destinatario dello stesso. Qualora tale
> messaggio sia stato ricevuto per errore, si prega di restituirlo al
> mittente e di cancellarlo permanentemente dal proprio computer.
> The information contained in this e mail message is strictly confidential
> and intended for the use of the addressee only. If you are not the
> intended recipient, please do not read, copy, forward or store it on your
> computer. If you have received the message in error, please forward it back
> to the sender and delete it permanently from your computer system.
> ------------------------------
>
>
> --
> Josh Vermaas
> Assistant Professor, MSU-DOE Plant Research Lab and Department of Biochemisty and Molecular Biologyvermaasj_at_msu.eduhttps://prl.natsci.msu.edu/people/faculty/josh-vermaas/ <https://urldefense.com/v3/__https://prl.natsci.msu.edu/people/faculty/josh-vermaas/__;!!DZ3fjg!vf1OksGrvmaNdGhfe05Ths_wW2XkImtUO-ap3ohAbsjbYDwiTZu5jMMDfiw4w_hyKw$>
>
>
This archive was generated by hypermail 2.1.6 : Fri Dec 31 2021 - 23:17:11 CST