Skip to content

extended Lagrangian is not compatible with NAMD's globalMaster MTS #793

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
fhh2626 opened this issue Apr 23, 2025 · 7 comments · May be fixed by #795
Open

extended Lagrangian is not compatible with NAMD's globalMaster MTS #793

fhh2626 opened this issue Apr 23, 2025 · 7 comments · May be fixed by #795

Comments

@fhh2626
Copy link
Contributor

fhh2626 commented Apr 23, 2025

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
@jhenin
Copy link
Member

jhenin commented Apr 23, 2025

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?

@fhh2626
Copy link
Contributor Author

fhh2626 commented Apr 23, 2025

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

@jhenin
Copy link
Member

jhenin commented Apr 23, 2025

Thanks, I will look into this.

@jhenin
Copy link
Member

jhenin commented Apr 23, 2025

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.

@fhh2626
Copy link
Contributor Author

fhh2626 commented Apr 24, 2025

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!

@jhenin jhenin linked a pull request Apr 25, 2025 that will close this issue
Open
3 tasks
@jhenin
Copy link
Member

jhenin commented Apr 25, 2025

@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.

@giacomofiorin
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Account for NAMD's GlobalMasterFrequency Colvars/colvars
3 participants
@giacomofiorin @jhenin @fhh2626