Skip to content

Conversation

@jeff231li
Copy link
Collaborator

Description

This PR adds support for calculating the free energy gradients for host-guest systems with the paprika protocol.

Status

  • Ready to go

@jeff231li
Copy link
Collaborator Author

Question: I noticed that the code in _evaluate_energies converts the potential energy to pint units but keeps it in kilojoule/mol. So the gradient I'm getting for energy parameters like LJ_epsilon becomes kilojoule/kilocalorie. What is the reason for keeping the potential energy in kilojoule/mol?

potentials[frame_index] = potential_energy.value_in_unit(
simtk_unit.kilojoule_per_mole
)
reduced_potentials[frame_index] = unreduced_potential * beta
potentials *= unit.kilojoule / unit.mole

@codecov
Copy link

codecov bot commented Jan 16, 2021

Codecov Report

Merging #342 (35828bf) into master (94c3703) will decrease coverage by 0.81%.
The diff coverage is 45.50%.

"n_pull_windows": n_pull_windows,
"release_windows_indices": [*range(len(attach_lambdas))],
"release_lambdas": release_lambdas,
"bound_window_index": [[*range(n_pull_windows)][0]],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should bound_window_index and unbound_window_index be lists, or can they just be single values? I think if they can be single values this will simplify _paprika_build_end_states_protocol by a fair bit!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I set bound_window_index and unbound_window_index as lists because template_values from ProtocolReplicator requires a list as input. Are you referring to setting template_value and template_index instead?

def apply(
self, protocols, template_values=None, template_index=-1, template_value=None
):

@jeff231li jeff231li requested review from dotsdl and j-wags February 24, 2021 17:32
@dotsdl
Copy link
Member

dotsdl commented Mar 1, 2021

Thanks @jeff231li! I've added this to my queue to review within the next week or so. Please ping if you require it more urgently!

@dotsdl
Copy link
Member

dotsdl commented Mar 16, 2021

@SimonBoothroyd I'm reviewing this PR this week; are there any areas of concern preventing merge? I'll prioritize getting the CI to pass first.

@SimonBoothroyd
Copy link
Contributor

SimonBoothroyd commented Mar 16, 2021

@SimonBoothroyd I'm reviewing this PR this week; are there any areas of concern preventing merge? I'll prioritize getting the CI to pass first.

I think the implementation looks like a great first pass, but currently contains large areas where code either duplicates already present functionalities (ComputePotentialEnergyGradient) or which can be significantly reduced (the schema definitions) which will take some careful thinking through.

Unfortunately I don't have the time at the moment to look over this and suggest the changes which will be required to be merge, so it may be some time before this will be able to be merged - my sincerest apologies for this delay!

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.

4 participants