colvars icon indicating copy to clipboard operation
colvars copied to clipboard

extended Lagrangian is not compatible with NAMD's globalMaster MTS

Open fhh2626 opened this issue 1 year ago • 7 comments

Hi all,

I recently found that extended-Lagrangian algorithms (e.g., eABF) are not compatible with NAMD's new globalMaster MTS. When running an eABF simulation with:

globalMasterFrequency 2
globalMasterScaleByFrequency off
globalMasterStaleForces on

NAMD outputs:

colvars:Detected discrete jump in colvar value from -72.463 to -67.3934.
colvars :Reinitializing extended coordinate to colvar value.
Synchronizing (emptying the buffer of)trajectory file "output/eabf.colvars.traj"
colvars :The restart output state file will be "output/eabf.restart.colvars.state".colvars :colvars:Initializing extended coordinate to colvar value.
colvars:Detected discrete jump in colvar value from -49.7613 to -52.3231.
colvars:Reinitializing extended coordinate to colvar value.
colvars :Initializing extended coordinate to colvar value.
colvars :Reinitializing extended coordinate to last value.Initializing extended coordinate to colvar value.

The values in the .czar.pmf file remain zero. In contrast, plain ABF works well with this new feature (all input files attached:

MTS.tar.gz

).

I suspect this issue arises because NAMD stores the last-step biasing force and performs an additional integration step for the real system, while not for the extended degrees of freedom. Consequently, Colvars detects discrepancies and attempts corrections every two steps. I recommend modifying Colvars to recognize the globalMasterStaleForces on setting, store the previous biasing force, and integrate the extended DOF independently of NAMD's communication.

Best, Haohao

fhh2626 avatar Apr 23 '25 05:04 fhh2626

Good catch, thank you Haohao!

We need to either support it fully or make it officially incompatible. Colvars' own MTS uses the impulse method, which is less biased than stale forces. Is there any reason to prefer the stale force to the impulse method?

jhenin avatar Apr 23 '25 08:04 jhenin

Good catch, thank you Haohao!

We need to either support it fully or make it officially incompatible. Colvars' own MTS uses the impulse method, which is less biased than stale forces. Is there any reason to prefer the stale force to the impulse method?

Thank you for your reply, Jérôme. The globalMaster MTS supports both the stale force and scaling-force methods. The impulse integrals of both methods should be equivalent. However, in some cases, the scaling-force method might apply large forces, triggering "atom moving too fast" errors. This occurs because Colvars forces evolve slowly but are not necessarily small in magnitude.

Best, Haohao

fhh2626 avatar Apr 23 '25 08:04 fhh2626

Thanks, I will look into this.

jhenin avatar Apr 23 '25 09:04 jhenin

The globalMaster MTS paradigm breaks an assumption (Colvars is called every timestep) made by many parts of the code: the extended Lagrangian is the tip of the iceberg. I'm working on a global fix.

jhenin avatar Apr 23 '25 17:04 jhenin

The globalMaster MTS paradigm breaks an assumption (Colvars is called every timestep) made by many parts of the code: the extended Lagrangian is the tip of the iceberg. I'm working on a global fix.

Thank you very much!

fhh2626 avatar Apr 24 '25 00:04 fhh2626

@fhh2626 now I can run your example correctly with the code from #795 if I add the parameter timeStepFactor 2 to all the colvars and to the abf bias. This should work in the future no matter what design decision we make.

jhenin avatar Apr 25 '25 09:04 jhenin

Thanks for pointing this out @fhh2626

I had raised the point of compatibility of globalMasterFrequency with Colvars features on the NAMD repo: https://gitlab.com/tcbgUIUC/namd/-/merge_requests/293#note_2182529407 but I have not followed up on that question or (better yet) opened an issue here

giacomofiorin avatar Apr 28 '25 16:04 giacomofiorin

(reopened because I accidentally merged #795 before it was finished)

giacomofiorin avatar Jul 08 '25 00:07 giacomofiorin