Lambda-ABF implementation for the NAMD interface #649

jhenin · 2024-01-19T12:48:28Z

As fully documented in the Lagardère et al. paper
complements the Tinker-HP implementation, which is maintained on the Tinker-HP repo.

TODO

Regression tests
Document current limitations in ref. manual

Update: why are there no regression tests? Because of a synchronization issue in NAMD, where the current alchemical colvar interface is plugged into a "non-urgent" output routine, which causes it to run in a variable order with respect to the Colvars calculation. This causes variations in the instantaneous trajectory, even though it cancels out of the ensemble averages, so the free energies are correct. This causes failures in regression tests, which are by design sensitive to trajectory details. The GPU-resident code path of NAMD is immune from this problem and produces reproducible trajectories: it is therefore the recommended way to use this code in NAMD.

fhh2626 · 2024-03-17T06:16:18Z

Hi @jhenin , I just read your excellent λ-ABF paper and then found this PR. I can't wait to give it a try. Is there any guide about how to write the Colvars file?
Thanks,
Haohao

jhenin · 2024-03-17T20:56:33Z

Hi Haohao,
The NAMD implementation still needs some refinement: it comes with performance limitations, namely, you cannot use MTS and you need energy computation every time step. Other than that, it works perfectly, and the performance is not so bad at all.

Here is an example input (using HMR):

timestep                2.0
fullElectFrequency      1
nonbondedFreq           1

# For NAMD3
computeEnergies 1

alch                    on
alchFile                        $alchconfig
alchCol                 B                    
alchOutFreq             1000

alchOutFile             $outName.fepout
alchElecLambdaStart     0.5                  
alchVdwLambdaEnd        1.0            
alchVdwShiftCoeff       5.0         
alchdecouple            on

alchType                TI
alchlambda 0

colvars                on 

cv config "
smp off  # Necessary for shared ABF
colvar {
  name l
  extendedLagrangian on
  extendedMass 150000
  extendedLangevinDamping 1000

   lowerBoundary 0
   upperBoundary 1
   reflectingLowerBoundary
   reflectingUpperBoundary
   width 0.01
  alchLambda {
  }
  outputTotalForce
  outputAppliedforce
}

 abf {
   colvars l
   fullSamples 1000
   outputFreq  50000
   historyFreq 100000
   shared on
   sharedFreq 5000
}
"

cv configfile $CVconfig
cv configfile common/protein_tilt.colvars

cv config "
colvarsTrajFrequency 100
colvarsRestartFrequency 100000"

fhh2626 · 2024-03-18T05:04:19Z

Hi Haohao, The NAMD implementation still needs some refinement: it comes with performance limitations, namely, you cannot use MTS and you need energy computation every time step. Other than that, it works perfectly, and the performance is not so bad at all.

Here is an example input (using HMR):

timestep                2.0
fullElectFrequency      1
nonbondedFreq           1

# For NAMD3
computeEnergies 1

alch                    on
alchFile                        $alchconfig
alchCol                 B                    
alchOutFreq             1000

alchOutFile             $outName.fepout
alchElecLambdaStart     0.5                  
alchVdwLambdaEnd        1.0            
alchVdwShiftCoeff       5.0         
alchdecouple            on

alchType                TI
alchlambda 0

colvars                on 

cv config "
smp off  # Necessary for shared ABF
colvar {
  name l
  extendedLagrangian on
  extendedMass 150000
  extendedLangevinDamping 1000

   lowerBoundary 0
   upperBoundary 1
   reflectingLowerBoundary
   reflectingUpperBoundary
   width 0.01
  alchLambda {
  }
  outputTotalForce
  outputAppliedforce
}

 abf {
   colvars l
   fullSamples 1000
   outputFreq  50000
   historyFreq 100000
   shared on
   sharedFreq 5000
}
"

cv configfile $CVconfig
cv configfile common/protein_tilt.colvars

cv config "
colvarsTrajFrequency 100
colvarsRestartFrequency 100000"

Thank you very much! Just one additional question. I need to use HMR to enable a timestep of 2fs?

jhenin · 2024-03-18T07:17:58Z

In alchemical simulations, I usually scale down the timestep, because one of the end points has a molecule in gas phase. Depending on the nature of the ligand, you may get stable simulations at larger timesteps.

fhh2626 · 2024-03-18T07:21:03Z

Thanks for your clarification!

fhh2626 · 2024-06-07T15:38:00Z

Hi, @jhenin ,
I suggest also make available the Colvars harmonic restraints as the alchemical CVs, which will let us completely give up FEP/TI in binding free energy calculations.
Haohao

jhenin · 2024-06-10T16:32:16Z

Hi, @jhenin , I suggest also make available the Colvars harmonic restraints as the alchemical CVs, which will let us completely give up FEP/TI in binding free energy calculations. Haohao

Thanks Haohao, I like the idea.

Save pointer to NAMD Controller in proxy this is necessary for accessing the Controller from threads other than 0 Simplify accelMD call Use alch lambda value from state file Dependencies updates and fixes - distinguish f_cv_gradient and f_cv_apply_force - rename external cvs "driven" - fix bug where error messages were not informative for complex dependency resolution failures Lambda-dynamics improvements - add total_force_current_step feature - follow lambda value from back-end Remove unused variables Enable scriptedColvarforces in ABMD script Allow scripted forces on external param Print unscaled biasing force in MTS

Select correct force bin on a per-colvar basis

So far is was erroneously set to true, but its effects were not fully implemented in ABF.

[update-doc]

removes spurious error messages

Had to force single-thread calculation to work around unreliable results on the singel timestep level

giacomofiorin

Looks good overall save for some minor comments.

giacomofiorin · 2024-12-13T16:31:37Z

src/colvardeps.h

+    /// \brief A variable that constrains or follows an external parameter
+    /// in the back-end (eg. an alchemical coupling parameter for lambda-dynamics)
+    /// If extended Lagrangian, then we drive the external parameter
+    /// Otherwise we follow it
    /// Can have a single component
    f_cv_external,


I would be okay with this in a pinch, but ideally I'd like to distinguish it from other "external" objects that are computed in a reproducible way (centers of mass, volumetric maps). Are you using this just to circumvent the check below?

cvm::error("Error: the calculated value of colvar \""+name+ "\":\n"+cvm::to_str(x)+"\n differs greatly from the value " "last read from the state file:\n"+cvm::to_str(x_restart)+ "\nPossible causes are changes in configuration, " "wrong state file, or how PBC wrapping is handled.\n", COLVARS_INPUT_ERROR);

It is used in many places in colvar.cpp. Another way to describe this feature is: this colvar is not a function of atom coordinates, it contains a special CVC that is communicated to and from the back-end through a separate mechanism. I'm happy to rename it if you have a better name, but I don't see an alternative to this feature.

src/colvardeps.h

src/colvarbias.cpp

src/colvarcomp.cpp

src/colvardeps.cpp

namd/src/colvarproxy_namd.h

giacomofiorin · 2024-12-13T16:50:45Z

src/colvar.cpp

+
+    // when total atomic forces are obtained from the previous time step,
+    // we cannot (currently) have colvar values and projected total forces for the same timestep
+    // TODO this will need refining for driven alchemical parameters


What do you mean by "driven alchemical parameters"?

"Driven" means Colvars is responsible for integrating (driving) the dynamics of this parameter. For the current version of this, see

colvars/src/colvar.cpp

Line 332 in 5e37f65

if (!is_enabled(f_cv_total_force_current_step)) {

src/colvar.cpp

- move step zero data test from colvarbias.cpp to ABF - properly test for driven external parameter

jhenin force-pushed the lambdadyn_namd branch from b1de04e to 833a970 Compare March 13, 2024 14:15

jhenin force-pushed the lambdadyn_namd branch 3 times, most recently from bb446e4 to ad9d897 Compare April 16, 2024 15:55

jhenin force-pushed the lambdadyn_namd branch 2 times, most recently from a325994 to b094ab9 Compare June 5, 2024 13:27

jhenin force-pushed the lambdadyn_namd branch 3 times, most recently from 0674e73 to ec218d0 Compare June 10, 2024 12:15

jhenin force-pushed the lambdadyn_namd branch 2 times, most recently from f580527 to d76c074 Compare September 1, 2024 08:18

jhenin force-pushed the lambdadyn_namd branch 2 times, most recently from 0e6d067 to 255a566 Compare September 22, 2024 17:20

jhenin force-pushed the lambdadyn_namd branch from 255a566 to 0790933 Compare October 18, 2024 14:55

jhenin marked this pull request as ready for review October 21, 2024 13:09

jhenin added 8 commits November 29, 2024 15:06

Better dependency failure messages for toplevel

8cc7672

Fix classic ABF in Tinker-HP

d3c34e0

Port ABF fix to TI bias

a31fd8e

Select correct force bin on a per-colvar basis

Fix total_forces_same_step flag for LAMMPS

1b10312

So far is was erroneously set to true, but its effects were not fully implemented in ABF.

Update LAMMPS regression tests for TI/ABF fix

5d1544f

Fix parsing of white-space only blocks

b99011a

NAMD doc for lambda-dynamics

299dbf0

[update-doc]

jhenin added 4 commits November 29, 2024 15:06

Finer choice of files to update in regtest script

c01fb5d

removes spurious error messages

First step towards MTS support in lambda-dynamics

9ab0c43

Regression test for lambda-ABF in NAMD

875ea4f

Had to force single-thread calculation to work around unreliable results on the singel timestep level

Doc improvements for NAMD/lambda-dyn

5e37f65

jhenin force-pushed the lambdadyn_namd branch from 0790933 to 5e37f65 Compare November 29, 2024 14:06

jhenin requested a review from giacomofiorin November 29, 2024 17:01

giacomofiorin reviewed Dec 13, 2024

View reviewed changes

Feature fixes after PR review

d6fc186

- move step zero data test from colvarbias.cpp to ABF - properly test for driven external parameter

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Lambda-ABF implementation for the NAMD interface #649

Lambda-ABF implementation for the NAMD interface #649

jhenin commented Jan 19, 2024 •

edited

Loading

fhh2626 commented Mar 17, 2024

jhenin commented Mar 17, 2024

fhh2626 commented Mar 18, 2024

jhenin commented Mar 18, 2024

fhh2626 commented Mar 18, 2024

fhh2626 commented Jun 7, 2024

jhenin commented Jun 10, 2024

giacomofiorin left a comment

giacomofiorin Dec 13, 2024

jhenin Dec 16, 2024

giacomofiorin Dec 13, 2024

jhenin Dec 16, 2024

Lambda-ABF implementation for the NAMD interface #649

Are you sure you want to change the base?

Lambda-ABF implementation for the NAMD interface #649

Conversation

jhenin commented Jan 19, 2024 • edited Loading

fhh2626 commented Mar 17, 2024

jhenin commented Mar 17, 2024

fhh2626 commented Mar 18, 2024

jhenin commented Mar 18, 2024

fhh2626 commented Mar 18, 2024

fhh2626 commented Jun 7, 2024

jhenin commented Jun 10, 2024

giacomofiorin left a comment

Choose a reason for hiding this comment

giacomofiorin Dec 13, 2024

Choose a reason for hiding this comment

jhenin Dec 16, 2024

Choose a reason for hiding this comment

giacomofiorin Dec 13, 2024

Choose a reason for hiding this comment

jhenin Dec 16, 2024

Choose a reason for hiding this comment

jhenin commented Jan 19, 2024 •

edited

Loading