-
Notifications
You must be signed in to change notification settings - Fork 14
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.
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
Avoiding tleap #197
Avoiding tleap #197
Conversation
"id": "9ee91f39-6968-448d-8173-38f0c14928b5", | ||
"metadata": {}, | ||
"source": [ | ||
"The experimental binding free energy is -8.27 kcal/mol<sup>1</sup>. To get a more accurate calculation we can decrease the step size of the attach fractions, increase the pull distance somewhat, decrease the step size between pull distances, to name a few options. Also realize that here we are only calculating the binding of rocuronium in one orientation to one face of sugammadex (primary).\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean to increase the number of steps (or increase sampling) in the attach phase?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I chose to say "decreasing the step size" because my attach fractions were given by np.arange()
, but if the attach fractions were not distributed evenly it would probably be more correct to say "increasing the number of fractions."
"name": "stderr", | ||
"output_type": "stream", | ||
"text": [ | ||
"2023-10-09 02:10:16 PM Note: detected 128 virtual cores but NumExpr set to maximum of 64, check \"NUMEXPR_MAX_THREADS\" environment variable.\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know a way to suppress these warning messages in Notebook? Not critical but it is a bit annoying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I add the line os.environ['NUMEXPR_MAX_THREADS'] = 'n'
on my machine to get it to shut up, but I don't know what library is dependent on numexpr
and causing this message. Is this caused by a pAPRika dependency?
" constraints=HBonds,\n", | ||
") # We recreate the OpenMM system because it now has waters\n", | ||
"\n", | ||
"# Set the nonbonded forces for the dummy atoms to have force constants of 0 and masses of 0.\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, if you set the masses to zero, then the dummy particles won't move at all throughout the simulation. Though we do apply strong harmonic positional restraints on them, I'm not sure what the effect of this is. I usually set the masses to the mass of lead -- 207 Dalton.
Also, with NonbondedForce
we are setting the partial charge and LJ parameters to zero not the force constant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point; I changed the mass from 207.2 to 0 at some point to see if there was any effect and never changed it back. I'll also update the comment to reflect what we're actually changing.
" ],\n", | ||
" )\n", | ||
" system.addForce(bond_restraint)\n", | ||
"\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not critical, but you could probably simplify the addition of these restraints with the function apply_dat_restraints
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using OpenMM Forces directly make it a little more verbose but I find it less confusing because the two pullings are separated: automatic pulling is left up to pAPRika and the manual pulling is done directly in OpenMM. If I were to change it to pAPRika restraints do you think it would be easier for users to follow the tutorial?
"with open(\"result.txt\", \"r\") as f:\n", | ||
" f.write(result_string)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be
with open("results.txt", "w") as f:
f.write(result_string)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how I made that mistake! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jaketanderson Looks good. Once you make the changes go ahead and merge the PR.
Jake, I didn’t review the Pr but make sure you list yourself as a collaborator / code author once this is merged. Sent from my iPhoneOn Oct 15, 2023, at 2:46 PM, Jeffry Setiadi ***@***.***> wrote:
@jeff231li approved this pull request.
@jaketanderson Looks good. Once you make the changes go ahead and merge the PR.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
I added a notebook to serve as a tutorial/template for setting up an APR calculation without using tleap. I chose the sugammadex-rocuronium host-guest pair for this.