Skip to content

Conversation

@Immi000
Copy link
Contributor

@Immi000 Immi000 commented Nov 10, 2025

I have a proposition for an alternative, more general implementation of the Beutler soft-core Lennard-Jones potential. The main difference to the previous version is that this implementation allows for the interpolation between two arbitrary soft-core Lennard-Jones potentials (or no interaction), with the freedom of choice which state is at which value of lambda. It also uses the standard Lennard-Jones force and potential functions internally, so any changes to these (e.g. performance-wise) will automatically be integrated into this soft-core formulation.

The implementation follows the formulation of the one in the GROMACS documentation.

This implementation has an additional factor of lambda in both the force and the potential that the old implementation was missing, I don't know whether that was intentional or a bug but I have adjusted the relevant tests.

This implementation also features a function ∂H_∂λ which computes the analytical derivative of the potential with respect to lambda $\frac{\partial H}{\partial\lambda}$ for thermodynamic integration. For now this is only accessible via custom logger or manually, but once there are more of these functions implemented for other soft-core potentials it might be worth adding standard support for them.

@codecov
Copy link

codecov bot commented Nov 10, 2025

Codecov Report

❌ Patch coverage is 0% with 101 lines in your changes missing coverage. Please review.
✅ Project coverage is 26.36%. Comparing base (a34f677) to head (1e3e86c).
⚠️ Report is 15 commits behind head on master.

Files with missing lines Patch % Lines
src/interactions/lennard_jones.jl 0.00% 101 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (a34f677) and HEAD (1e3e86c). Click for more details.

HEAD has 10 uploads less than BASE
Flag BASE (a34f677) HEAD (1e3e86c)
11 1
Additional details and impacted files
@@             Coverage Diff             @@
##           master     #227       +/-   ##
===========================================
- Coverage   68.10%   26.36%   -41.74%     
===========================================
  Files          43       45        +2     
  Lines        8816     9091      +275     
===========================================
- Hits         6004     2397     -3607     
- Misses       2812     6694     +3882     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@jgreener64
Copy link
Member

Thanks for this. We are still working out the best way to implement alchemical features. Currently we use a dual topology approach where atoms can be turned on or off with λ but can't be modified from one atom to another.

If we do allow a single topology approach where atoms can change from one type to another this could be useful. In that case we would probably want to store the σ/ϵ parameters from each state in the atom.

This implementation has an additional factor of lambda in both the force and the potential that the old implementation was missing, I don't know whether that was intentional or a bug but I have adjusted the relevant tests.

That is indeed a bug and should be fixed.

@Immi000
Copy link
Contributor Author

Immi000 commented Nov 26, 2025

Alright, thanks for the reply. I would be interested in a single topology approach allowing for interpolation of atoms for alchemical transformations for the purpose of free energy calculations. This should be general enough to allow for on/off switching as well as transformations of the interactions. I am not sure how much work is required to put this into a general framework, but in my (admittedly quite minimal) experiments no modifications to other parts of the simulation were necessary.

Do you have any concrete plans for the future whether and if yes how you would like to see this implemented?

@jgreener64
Copy link
Member

Not much concrete yet, but it would probably require a new atom type (to store the σ/ϵ at each end point) and consideration of how e.g. bond parameters move smoothly between the end points.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants