Question: Is there a way to apply a constraint on top of ABF?

[ruyeli]

Dear Colvars developers,

I’m using the ABF implementation in NAMD to calculate the free-energy profile of a drug permeating through a lipid bilayer. My colvar is defined as the z-distance between the center of mass of the drug and the membrane. During the simulations I have encountered poor sampling and slow convergence in some windows. Thus I’m considering adding a second colvar to apply a restraint within the drug, effectively constraining its conformation.

However, I’m concerned about how this extra restraint will affect the resulting PMF. The subtractAppliedForce documentation notes that removal of all other external forces (including biasing forces applied to a different colvar) is no longer supported, so I’m not sure how to exclude this additional bias from the final free-energy calculation. At the same time, I’m wondering whether a two-dimensional ABF might work. Are these two colvars, the translocation coordinate and the internal restraint considered orthogonal, given that they share drug atoms?

Could you please advise whether it is reasonable (and physically valid) to apply a secondary restraint on the drug? Alternatively, would a 2D-ABF approach be possible in this case?

Thank you very much for your guidance.

Best,
Ruye Li

[giacomofiorin]

Hi Ruye, the orthogonality requirement applies to the forces generated by holonomic constraints, not by restraints. Therefore, the projection of the force field's forces onto the colvar (a z coordinate, in this case) would still be valid.

Restraint forces, if constant, would be treated as if they were part of the force field, i.e. the free-energy computed by ABF would include their contribution, consistent with what other methods such as umbrella sampling, metadynamics etc would give you.

While you may want to remove the contribution of these forces from the PMF, it is important to remind that by adding the restraint you are also restricting the simulated trajectory in a way that cannot be easily accounted for. That is, if the minimum free-energy path (MFEP) has the molecule always close to the restrained conformation, the contribution of the restraint to the PMF should be negligible. On the other hand, if the MFEP requires the molecule to change conformation, the restraint energy would be significant.

As a practical suggestion, I would enable outputEnergy on the additional restraint and monitor its value during the simulation to make sure that it doesn't change significantly along the path.

[ruyeli]

Hi Giacomo,

Thank you very much for the clarification, this really helps a lot!

[HanatoK]

If you use ABF, then you have to ensure the orthogonality requirement of external restraints, since ABF relies on the integration of local gradients to get the PMF instead of reweighting from the bias energy. If you use eABF and do want reweighting for excluding the contribution of restraints, you could try the idea in https://pubs.aip.org/aip/jcp/article/157/2/024110/2841454 that uses MBAR for reweighting. However, it is not implemented in Colvars.

If you use metadynamics, then you can use the sum of bias energies from metadynamics and the restraints to perform reweighting. A reweighting method can be found in dx.doi.org/10.1021/jp504920s. The reweighting can allow you to get rid of the contribution of restraints. Unfortunately, it looks like that @giacomofiorin are not interested in implementing the reweighting estimator for metadynamics in Colvars. Unfortunately, the reweighting estimator for metadynamics has never been implemented in Colvars.

If you use OPES, then reweighting accounting for other restraints is easy in theory. However, since Colvars does not support using a colvarbias as the input of another colvarbias object, I cannot implement it (see the TODO at the following code).

colvars/src/colvarbias_opes.cpp

Lines 566 to 568 in 5344dc0

	// TODO: how could I account for extra biases in Colvars?
	const cvm::real log_weight = bias_energy / m_kbt;
	cvm::real height = cvm::exp(log_weight);

PLUMED code (https://github.com/plumed/plumed2/blob/940f6e80f0f35d41d220d0d34c207d792be4b3c8/src/opes/OPESmetad.cpp#L1023-L1028):

double log_weight=getOutputQuantity(0)/kbt_; //first value is always the current bias
for(unsigned e=0; e<extra_biases_.size(); e++) {
  log_weight+=extra_biases_[e]->get()/kbt_;  //extra biases contribute to the weight
}
double height=std::exp(log_weight);

In summary, for all free-energy methods in Colvars, you have to ensure the orthogonality requirement of external restraints.

I think this discussion is worth converting back to an issue until Colvars allows to use the output of a bias as the input of other bias.

[giacomofiorin]

Unfortunately, it looks like that @giacomofiorin are not interested in implementing the reweighting estimator for metadynamics in Colvars.

Could you please reference the relevant discussion about this point?

[HanatoK]

Unfortunately, it looks like that @giacomofiorin are not interested in implementing the reweighting estimator for metadynamics in Colvars.

Could you please reference the relevant discussion about this point?

Sorry. I remember there was a discussion in the NAMD mailing list a long time ago, but probably my impression is wrong. I will change my answer.

[giacomofiorin]

Sorry. I remember there was a discussion in the NAMD mailing list a long time ago, but probably my impression is wrong. I will change my answer.

I genuinely didn't remember, and thought you had better memory: I'll look for that NAMD list message. Hopefully there wasn't major refactoring needed? Otherwise, Tiwary's method would be useful to support (especially if it's post-processing?)

@fabsugar can you comment about how to handle reweighting of restraints with FCAM?

[ruyeli]

Thank you so much for these careful and detailed suggestions. I realize there are a lot of technical issues here, but I’ll try to work them out. I really appreciate your guidance!

[HanatoK]

I searched the mailing list and strangely found nothing about metadynamics and reweighting, so I guess I had the wrong impression. The reweighting estimator is useful especially when you want (i) applying bias along CV1 while estimating the free energy along CV2, and (ii) accounting for the effects of restraints. To fully support (ii), we need a major refactoring in Colvars to support using the energy of a colvarbias as the input of another colvarbias. Of course, this can be circumvented by post-processing, but that means less trajectory samples are used, which reduces the numerical accuracy. For the same reason, the reweighting estimator in OPES only achieves (i).

…

On Mon, Jul 7, 2025, 17:04 Giacomo Fiorin ***@***.***> wrote: Sorry. I remember there was a discussion in the NAMD mailing list a long time ago, but probably my impression is wrong. I will change my answer. I genuinely didn't remember, and thought you had better memory: I'll look for that NAMD list message. Hopefully there wasn't major refactoring needed? Otherwise, Tiwary's method would be useful to support (especially if it's post-processing?) @fabsugar <https://github.com/fabsugar> can you comment about how to handle reweighting of restraints with FCAM? — Reply to this email directly, view it on GitHub <#813 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF4Y6AS67JXUI5P6QTBAYKT3HLVGFAVCNFSM6AAAAACARO3LYWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNRYHA4DKOA> . You are receiving this because you commented.Message ID: ***@***.***>

[giacomofiorin]

Thanks for checking!

I think that being able to use the energy of a colvarbias as the input of another colvarbias is a feature worth adding, even if only to support OPES (which could be a better alternative to well-tempered metadynamics).

I'm not sure that this would require a major refactoring: I'll look into it.