Hi Matthew,
I think your approach is fine--the SC region doesn't need to have an integer total charge. Nevertheless, it is still debatable about the best way to define the softcore region. With a larger SC region, you would get better sampling but worse convergence. The maximum common structure (MCS) is probably the most popular approach. I usually use MCS but avoid any C-H bond across the common atom/softcore boundary, e.g., for the mutation C-H --> C-F, I would include C-H (and C-F) both atoms in the softcore region but MCS would only include H/F.
Hope it helps.
Best,
Taisung
-----Original Message-----
From: Matthew Guberman-Pfeffer <matthew.guberman-pfeffer.uconn.edu>
Sent: Thursday, November 10, 2022 10:45 PM
To: accuratefreeenergy.gmail.com; AMBER Mailing List <amber.ambermd.org>
Subject: Re: {SPAM?} Re: [AMBER] Alchemical gti keyword questions
Hi Taisung,
Thank you so much for your replies! I’m trying to learn about alchemical calculations from scratch, and I naturally worry about everything I don’t yet understand, Thanks for pointing me to the literature.
Following up on your last comment, I’d like to ask about defining the TI region. Currently, I specify the entire residue as the TI region and only the unique atoms of the side chain as the softcore region. This leaves the backbone to be linearly scaled, even though only the partial charge on the alpha carbon changes because of the mutation. Does this sound reasonable? Would you suggest a different approach?
Best,
Matthew
> On Nov 8, 2022, at 8:21 AM, accuratefreeenergy--- via AMBER <amber.ambermd.org> wrote:
>
> *Message sent from a system outside of UConn.*
>
>
> Hi Matt,
>
>
>
> See below my comments/answers in red.
>
>
>
> Taisung
>
>
>
>
> Is option 3 to the gti_add_sc keyword the “fix” to the problem with alchemical transformations in AMBER reported in <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubs.acs.org%2Fdoi%2Fabs%2F10.1021%2Facs.jpcb.8b04187&data=05%7C01%7C%7Cabf0fd5f5af6479abf4008dac18c425c%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C638035105404171057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dDkYIxjpaNNn2t16Vmlw0ebPxwWLAbia4E7FXI6yfR8%3D&reserved=0> J. Phys. Chem. B 2017, 121 (20), 5151−5161? If so, how can I tell when I need to switch from the default option of gti_add_sc=1? Is there a reason why “3” is not the default?
>
>
>
> Yes. Theoretically gti_add_sc>1 will give you right answers hence there is no reason to set 3 as the default. “1” is the default because it produces results similar to other implementations.
>
>
> Also, if bonded terms that cross the softcore-common core boundary should be removed, why is the default to gti_bat_sc to retain all bonded terms? How can I tell when to change to option 1 or 2 for this keyword. (By the way, how does option 1—where the program decides what bonded terms to retain—work?)
>
>
>
> Theoretically bonded terms can be all scaled or kept with some rules. When all of them are scaled, the simulation will be extremely difficult to converge and one needs to be very careful to handle this issue. The default behavior is NOT to scale any bonded term (similar to other implementations) to avoid user-errors. If you don’t understand the theoretic details, I suggest you use the default values. Or you can read this paper first <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1021%2Facs.jctc.0c01328&data=05%7C01%7C%7Cabf0fd5f5af6479abf4008dac18c425c%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C638035105404171057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V%2B7XXHGR%2BsKrShckRh%2FJsMGzFKePHY%2BbwxiGWf6yGho%3D&reserved=0> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1021%2Facs.jctc.0c01328&data=05%7C01%7C%7Cabf0fd5f5af6479abf4008dac18c425c%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C638035105404171057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V%2B7XXHGR%2BsKrShckRh%2FJsMGzFKePHY%2BbwxiGWf6yGho%3D&reserved=0
>
>
>
> These questions are motivated by a large discrepancy I obtained when trying to compute the Delta_G for the W6F mutation in the Trp-cage peptide. I obtained a Delta_G of +7.4 kJ/mol, but the reported <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flink.springer.com%2Fprotocol%2F10.1007%2F978-1-4939-8736-8_2&data=05%7C01%7C%7Cabf0fd5f5af6479abf4008dac18c425c%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C638035105404171057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ldCzQO032lSxzj0ncma21ha%2BgLaNqlARDCapL80CkYo%3D&reserved=0> value is -4.29 kJ/mol. I equilibrated the initial and final states, and took 70 200-ps-equally spaced snapshots from each to initiate fast-growth transitions in the A->B and B->A directions, respectively. Each morphing simulation was 200 ps in the NPT ensemble. When I use the free energy estimators implemented in the PMX package, I obtain the below result. I’d greatly appreciate any thoughts/suggestions on what I’m doing wrong. I’m happy to provide more details if that’d be helpful.
>
>
>
> Since different definitions and treatments of the SC regions will give different \Delta G values, it is not meaningful to compare \Delta Gs. You need to compare \Delta \Delta Gs where the SC internal energies are cancelled out.
>
>
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.ambermd.org%2Fmailman%2Flistinfo%2Famber&data=05%7C01%7C%7Cabf0fd5f5af6479abf4008dac18c425c%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C638035105404171057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IaWmpHkrShPRIuN%2Bg0jqJG%2FWQjIngwMCpEFPQb1JzQY%3D&reserved=0
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sat Nov 12 2022 - 05:30:02 PST
